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ARTICLE OF MANUFACTURE FOR COMPONENT BASED NEGOTIATION 
FACILITATING DURING CLAIM PROCESSING 

FIELD OF THE INVENTION 

The present invention relates to negotiation management and more particularly to facilitating 
negotiation during insurance claim processing using event generation. 

BACKGROUND OF THE INVENTION 

Computers have become a necessity in life today. They appear in nearly every office and 
household worldwide. A representative hardware environment is depicted in prior art Figure 1, 
which illustrates a typical hardware configuration of a workstation having a central processing 
unit 110, such as a microprocessor, and a number of other units interconnected via a system bus 
112. The workstation shown in Figure 1 includes a Random Access Memory (RAM) 1 14, Read 
Only Memory (ROM) 116, an I/O adapter 118 for connecting peripheral devices such as disk 
storage units 120 to the bus 112, a user interface adapter 122 for connecting a keyboard 124, a 
mouse 126, a speaker 128, a microphone 132, and/or other user interface devices such as a touch 
screen (not shown) to the bus 112, communication adapter 134 for connecting the workstation to 
a communication network (e.g., a data processing network) and a display adapter 136 for 
connecting the bus 112 to a display device 138. The workstation typically has resident thereon 
an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), 
the IBM OS/2 operating system, the MAC OS, or UNIX operating system. 

Object oriented programming (OOP) has become increasingly used to develop complex 
applications. As OOP moves toward the mainstream of software design and development, 
various software solutions require adaptation to make use of the benefits of OOP. A need exists 
for these principles of OOP to be applied to a messaging interface of an electronic messaging 
system such that a set of OOP classes and objects for the messaging interface can be provided. 
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limitation or detail to it. The object representing the ceramic piston engine "depends from" the 
object representing the piston engine. The relationship between these objects is called 
inheritance. 

When the object or class representing the ceramic piston engine inherits all of the aspects of the 
objects representing the piston engine, it inherits the thermal characteristics of a standard piston 
defined in the piston engine class. However, the ceramic piston engine object overrides these 
ceramic specific thermal characteristics, which are typically different from those associated with 
a metal piston. It skips over the original and uses new functions related to ceramic pistons. 
Different kinds of piston engines have different characteristics, but may have the same 
underlying functions associated with it (e.g., how many pistons in the engine, ignition sequences, 
lubrication, etc.). To access each of these functions in any piston engine object, a programmer 
would call the same functions with the same names, but each type of piston engine may have 
different/overriding implementations of functions behind the same name. This ability to hide 
different implementations of a function behind the same name is called polymorphism and it 
greatly simplifies communication among objects. 

With the concepts of composition-relationship, encapsulation, inheritance and polymorphism, an 
object can represent just about anything in the real world. In fact, the logical perception of the 
reality is the only limit on determining the kinds of things that can become objects in object- 
oriented software. Some typical categories are as follows: 

• Objects can represent physical objects, such as automobiles in a traffic-flow simulation, 
electrical components in a circuit-design program, countries in an economics model, or 
aircraft in an air-traffic-control system. 

• Objects can represent elements of the computer-user environment such as windows, 
menus or graphics objects. 

• An object can represent an inventory, such as a personnel file or a table of the latitudes 
and longitudes of cities. 

• An object can represent user-defined data types such as time, angles, and complex 
numbers, or points on the plane. 

With this enormous capability of an object to represent just about any logically separable 
matters, OOP allows the software developer to design and implement a computer program that is 
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SUMMARY OF THE INVENTION 



A computer program is provided for developing component based software capable of 
facilitating insurance-related negotiation. The program includes a data component that stores, 
retrieves and manipulates data utilizing a plurality of functions. Also provided is a client 
component that includes an adapter component that transmits and receives data to/from the data 
component. The client component also includes a business component that serves as a data 
cache and includes logic for manipulating the data. A controller component is also included 
which is adapted to handle events generated by a user utilizing the business component to cache 
data and the adapter component to ultimately persist data to a data repository. In use, the client 
component provides a plurality of data fields relating to an insurance-related negotiation. In 
addition, a plurality of rules are provided which dictate events to be raised based on data in the 
data fields. The user is then able to input data into the data fields. Finally, events are raised 
based on the data entered into the data fields. The events raised in turn can 'be used to create a 
task. 
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DESCRIPTION OF THE DRAWINGS 

The foregoing and other objects, aspects and advantages are better understood from the 
followng detailed description of a preferred embodiment of the invention with reference to the 
drawings, in which: 

Prior Art Figure 1 is a schematic diagram of the present invention; and 
Figure 2A is block diagram of one embodiment of the present invention. 

Figure 2B is a flowchart showing how components generally operate in accordance with one 
embodiment of the present invention. 

Figure 2C is a flowchart showing how the UI Controller operates in accordance with one 
embodiment of the present invention. 

Figure 2D is a flowchart showing .he inactions belwcen , he ^ ^ ^ ^ fc 
Component j„ accordance with one embodiment of (he present invention. 

Figure 3 shows the iife cycle of, typica, User interface and the standard methods tha, are part of 
the Window Processing Framework. 

Figure 4 is an illustration showing how different languages are repainted and recompiled. 
Figure 5 is a block diagram of an Architecture Object. 

Figure 6 ,s an illustration showing the physical layout of CodeDecode tables according to one 
embodiment of the present invention. 

Figure 7 is a logic diagram according to one embodiment of the present invention. 
Figure 8 is a block diagram of the security framework and its components. 
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Figure 9 is an illustration showing the relationships between the security element and other 
elements- 
Figure 10 is an illustration of the Negotiation component of one embodiment of the present 
5 invention; 

Figure 11 is a flow diagram of the operations carried out by the Organization component of one 
embodiment of the present invention; 

10 Figure 12 is an illustration of the Participant component of one embodiment of the present 
invention; 

Figure 13 is a flow diagram of the operations carried out by the Task Assistant component of one 
embodiment of the present invention; 

15 

Figure 14 is an illustration of the Event Processor in combination with other components of the 
system in accordance with on embodiment of the present invention; and 

Figure 15 is an illustration of the Task Engine in accordance with one embodiment of the present 
20 invention. 



7 



WO 00/67186 



PCTAJSOO/12508 



DISCLOSURE OF THE INVENTION 

Programing languages are beginning to fully support the OOP principles, such as 
encapsulation, inheritance, polymorphs, and composition-relationship. With the advent of the 
C++ language, many commercial software developers have embraced OOP C++ is an OOP 
language that offers a fast, machine-executable code. Furthermore, C++ is suitable for both 
commercial-apphcanon and systems-programming projects. For now, C++ appears to be the 
most popular choice among many OOP programmers, but there is a host of other OOP 
languages, such as Smalltalk, Common Lisp Object System (CLOS), and HUH. Addmonally 

sue!" 

Tne benefits of objecl classes can be summarized, as follows: 

• Obiccs and their corresponding classes break down complex programming problem, into 
many smaller, simpler problems. 

• Encapsulation enforces data abstraction through the organization of data into small 
independent objects that can communicate with each other. Encapsulation protects the 
data m an object from accidental damage, but al.ows other objects to interact with that 
data by calling the object's member functions and structures. 

• Subc.assmg and .nhentance make it possible to extend and modify objects through 
denvmg new kinds of objects from the standard classes available in the system Thus 
new capab.hties are created without having to start from scratch. 

• Polymorphism and multiple inheritance make it possible for different programmers to 
m.x and match characteristics of many different classes and create specialized objects 
that can still work with related objects in predictable ways. 

Class hierarchies and containment hierarchies provide a flexible mechanism for modeling 
real-world objects and the relationships among them. 

Libraries of reusable classes are useful in many stations, but they also have some 
limitations. For example: 

Complexity. In a complex system, the class hierarch.es for related classes can become 
extremely confusmg, with many dozens or even hundreds of classes. 

8 
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• Flow of control. A program written with the aid of class libraries is still responsible for 
the flow of control (i.e., it must control the interactions among all the objects created 
from a particular library). The programmer has to decide which functions to call at what 
times for which kinds of objects. 

• Duplication of effort. Although class libraries allow programmers to use and reuse many 
small pieces of code, each programmer puts those pieces together in a different way. 
Two different programmers can use the same set of class libraries to write two programs 
that do exactly the same thing but whose internal structure (i.e., design) may be quite 
different, depending on hundreds of small decisions each programmer makes along the 
way. Inevitably, similar pieces of code end up doing similar things in slightly different 
ways and do not work as well together as they should. 

Class libraries are very flexible. As programs grow more complex, more programmers are 
forced to reinvent basic solutions to basic problems over and over again. A relatively new 
extension of the class library concept is to have a framework of class libraries. This framework 
is more complex and consists of significant collections of collaborating classes that capture both 
the small scale patterns and major mechanisms that implement the common requirements and 
design in a specific application domain. They were first developed to free application 
programmers from the chores involved in displaying menus, windows, dialog boxes, and other 
standard user interface elements for personal computers. 

Frameworks also represent a change in the way programmers think about the interaction between 
the code they write and code written by others. In the early days of procedural programming, the 
programmer called libraries provided by the operating system to perform certain tasks, but 
basically the program executed down the page from start to finish, and the programmer was 
solely responsible for the flow of control. This was appropriate for printing out paychecks, 
calculating a mathematical table, or solving other problems with a program that executed in just 
one way. 

The development of graphical user interfaces began to turn this procedural programming 
arrangement inside out. These interfaces allow the user, rather than program logic, to drive the 
program and decide when certain actions should be performed. Today, most personal computer 
software accomplishes this by means of an event loop which monitors the mouse, keyboard, and 



WO 00/67186 

PCT/USOO/12508 

«h™ of external events and .Us the wropnale pam rf fc programmer , s 
a«ord,„g ,„ ac(ions „,„ l|K _ perfomK ^ programmer ^ 

t^ctable limes ^ in . unpredjctab , e orfer fiy ^ con|roi 
«. deve,o P er creates a p rograin te is much ^ l0 use . Ne 

program w™,e„ by fc developer am M „ „ branes by ^ P « 

"T" Mnain ^ " ,d ,he — •* «e.ennine the flow of control Wllhi „ 

- P- aner ,,, cafled by fc eveM Ioop . Applicalion ^ „ siB m of , *^ 

Even e Vent ^ ^ ^ ^ ^ ^ ^ ^ 

wnt,™ aepa^y f „ r ever, „, ^ of an app„ca,,o„ ^eworK carn es fc 

even, tap eoncec, fcrther . ^ ^ ^ ^ fc _ ^ ^ ^ * 

menus, wrndows, ^ d ,a,o g te es aaa ften mating lhese a „ ^ 

-« frameworks star, wift wockang a PP ,.ca,io„ code ^ ^ ^ fc £ ~ 

capao.1,. of ft. framework wift ft. apecifrc rapabl „, jes rf fc ^ 

tZTZTC 11,5 ,0,al -"" of ^ 1 pr ~ - - — - 

Z2 " 5 re "" y 3 *- widows 

sup,™ copy ^ paae , Md so on, fte programmer can afso re ,„ q „i sn ^ „ S ' 
ftan even, lTOp programs ^ ^ ^ ^ ^ 

^ - How of con*,,, and fte P rogrammer- s code is ca„ed o„ ly vrnen , he firework 
nee* it (e.g„ to create or manipulate a proprielary data strucrure). 

A pr~r wriUng a Rework program no( only relm^ea conrro, ,„ ft, user (as „ als0 
«• for even. !oo P P rog™ S ), „„ aiso reft^es fte detaiied n„w of ccntto, wi ft„ ft e 

™ S ~ "™ - — of more eom P ,ea systems thal 
wo* ^gefter ,„ mteresring ways , as opposed „ ^ ^ 

created over and over aga i„ for similar problenK . " 8 
make up a, eaaabledesrgnsotaion for a given problem domain It tyoicallv include h' , 



10 



WO 00/67186 



PCT/US00/12508 



some of that default behavior and overriding other behavior so that the framework: calls 
application code at the appropriate times. 

There are three main differences between frameworks and class libraries: 

• Behavior versus protocol. Glass libraries are essentially collections of behaviors that you 
can call when you want those individual behaviors in your program. A framework, on 
the other hand, provides not only behavior but also the protocol or set of rules that govern 
the ways in which behaviors can be combined, including rules for what a programmer is 
supposed to provide versus what the framework provides. 

• Call versus override. With a class library, the code the programmer instantiates objects 
and calls their member functions. It's possible to instantiate and call objects in the same 
way with a framework (i.e., to treat the framework as a class library), but to take full 
advantage of a framework's reusable design, a programmer typically writes code that 
overrides and is called by the framework. The framework manages the flow of control 
among its objects. Writing a program involves dividing responsibilities among the 
various pieces of software that are called by the framework rather than specifying how 
the different pieces should work together. 

• Implementation versus design. With class libraries, programmers reuse only 
implementations, whereas with frameworks, they reuse design. A framework embodies 
the way a family of related programs or pieces of software work. It represents a generic 
design solution that can be adapted to a variety of specific problems in a given domain. 
For example, a single framework can embody the way a user interface works, even 
though two different user interfaces created with the same framework might solve quite 
different interface problems. 

Thus, through the development of frameworks for solutions to various problems and 
programming tasks, significant reductions in the design and development effort for software can 
be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language 
(HTML) to implement documents on the Internet together with a general-purpose secure 
communication protocol for a transport medium between the client and the Newco. HTTP or 
other protocols could be readily substituted for HTML without undue experimentation. 
Information on these products is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext 
Markup Language - 2.0" (Nov. 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and 

U 
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compliant, general-purpose programming language. Java supports programming for the Internet 
in the form of platform-independent Java applets." Java applets are small, specialized 
applications that comply with Sun's Java Application Programming Interface (API) allowing 
developers to add "interactive content" to Web documents (e.g., simple animations, page 
5 adornments, basic games, etc.). Applets execute within a Java-compatible browser (e.g., 

Netscape Navigator) by copying code from the server to client. From a language standpoint, 
Java's core feature set is based on C++. Sun's Java literature states that Java is basically, "C++ 
with extensions from Objective C for more dynamic method resolution." 

10 Another technology that provides similar function to JAVA is provided by Microsoft and 

ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic 
content for the Internet and personal computers. ActiveX includes tools for developing 
animation, 3-D virtual reality, video and other multimedia content. The tools use Internet 
standards, work on multiple platforms, and are being supported by over 100 companies. The 

15 group's building blocks are called ActiveX Controls, small, fast components that enable 

developers to embed parts of software in hypertext markup language (HTML) pages. ActiveX 
Controls work with a variety of programming languages including Microsoft Visual C++, 
Borland Delphi, Microsoft Visual Basic programming system and, in the future, Microsoft's 
development tool for Java, code named "Jakarta." ActiveX Technologies also includes ActiveX 

20 Server Framework, allowing developers to create server applications. One of ordinary skill in 
the art readily recognizes that ActiveX could be substituted for JAVA without undue 
experimentation to practice the invention. 

25 Detailed Description 

One embodiment of the present invention is a server based framework utilizing component based 
architecture. Referring to Figure 2A, one embodiment of the present invention includes an 
Architecture Object 200, an Application Object 202, a User Interface Form 204, a User Interface 
30 Controller 206, a Client Component Adapter 208, a COM Component Interface 2 1 0, and a 
Server Component 222. 

In general, the components of the present invention operate as shown in Figure 2B. In step 230, 
data is stored in an object of the component. In step 232, functions which manipulate the object 
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- 'a,e burdtng to i„s,an,ia,e targe, U, connohers in order ,„ provide an,„„„ my b e,wee„ 



ication. 
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windows. This allows different controllers to use the Application Object 202 without statically 
linking to each and every Ul controller in the application. 



When opening a UI controller, the Application Object 202 calls the architecture initialization, 
class initialization, and form initialization member functions. 

The Application Object 202 keeps a list of every active window, so that it can shut down the 
application in the event of an error. When a window closes, it tells the Application Object 202 , 
and is removed from the Application Object's 202 list of active windows. 

The Application Object 202 is responsible for instantiating each UI Controller 206, passing data / 
business context to the target UI Controller 206, and invoking standard services such as initialize 
controller, initializing Form and Initialize Architecture. The Application Object 202 also keeps 
track of which windows are active so that it can coordinate the shutdown process. 

UI Form 

The UI form's 204 primary responsibility is to forward important events to its controller 206. It 
remains mostly unintelligent and contains as little logic as possible. Most event handlers on the 
form simply delegate the work by calling methods on the form's controller 206. 

The Ul form 204 never enables or disables its own controls, but ask its controller 206 to do it 
instead. Logic is included on the Ul form 204 only when it involves very simple field masking 
or minor visual details. 

The Ul form 204 presents an easy-to-use, graphical interface to the user and informs its 
controller 206 of important user actions. The UI form 204 may also provide basic data 
validation (e.g., data type validation) through input masking. In addition, the UI form is 
responsible for intelligently resizing itself, launching context-sensitive help, and unload itself. 

User Interface Controller 

Every UI Controller 206 includes a set of standard methods for initialization, enabling and 
disabling controls on its UI form 204, validating data on the form, getting data from the Ul form 
204, and unloading the UI form 204. 
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UI Controllers 206 contain the majority of logic to manipulate Business Objects 207 and 
the appearance of its UI form 204 rf it. r • ness Ejects 207 and manage 

us ui lorm 204. If its form is not read-only the in Cnntmti ™* , 

when fc userdecides t0 save fc ^ ^ of ™es 

Rgore 2C is a flowchart showing how the „ Con(ro|leroperates .„ 

fc-P^aisen.eredinaU.fortnnv^. * 

appropnatc dau ,„«o a B„ siness Obj M ,„ be u u ll2 ed and retteved .a, w . 

A UI Controller 206 defines a Logical Unit of Won. (LUW) IfanLUWin ■ 

2™,' lh T " USineS! ° bjeC,S 207 ^ — UI Connoller 
uojects ^U7, and handles aU client-side < 



J errors. 



Business Objects 

0bjeC '' S (B0> «~> " — a dau holder, alowing data ,„ 

be shared across User ,„,erfaee C„„rro,le. 20o -sing an oo.ec.-base,, pr „ g 

BOs 207 perform vahdahon on .heir arWhuies a, ,he y are being se, ,o nra^ain lhe iMegriry of 
"22: me,h0dSB ^ fclife ~— 202or.odenve.be valaeofa 
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Business Objects 207 contain information about a single business entity and maintain the 
integrity of that information. The BO 207 encapsulates business rules that pertain to that single 
business entity and maintains relationships with other business objects (e.g., an insurance claim 
contains a collection of supplements). Finally, the BO 207 provides additional properties 
relating to the status of the information it contains (such as whether that information has changed 
or not), provides validation of new data when necessary, and calculates attributes that are derived 
from other attributes (such as Full Name, which is derived from First Name, Middle Initial, and 
Last Name). 

Client Component Adapters 

Client Component Adapters (CCAs) 208 are responsible for retrieving, adding, updating, and 
deleting business objects in the database. CCAs 208 hide the storage format and location of data 
from the UI controller 206. The UI controller 206 does not care about where or how objects are 
stored, since this is taken care of by the CCA 208. 

The CCA 208 marshals data contained in recordsets returned by the server into business objects 
207. CCAs 208 masks all remote requests from UI Controller 206 to a specific component, and 
act as a "hook" for services such as data compression, and data encryption. 

COM Component Interface 

A COM Component Interface (CCI) 210 is a "contract" for services provided by a component. 
By "implementing" an interface (CCI) 210, a component is promising to provide all the services 
defined by the CCI 20. 

The CCI 210 is not a physical entity (which is why it is depicted with a dotted line). It's only 
reason for existence is to define the way a component appears to other objects. It includes the 
signatures or headers of all the public properties or methods that a component will provide. 

To implement a CCI 210, a server component exposes a set of specially named methods, one for 
each method defined on the interface. These methods should do nothing except delegate the 
request to a private method on the component which will do the real work. 
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The CCI 2 1 0 defines a set of related services provided by a component. The CCI allows any 
component to -hide" behind the interface to perform the services defined by the interface by 
"implementing" the interface. 

Server Component 

Server components 222 are course grained and transaction oriented. They are designed for 
maximum efficiency. 

Server Components 222 encapsulate all access to the database, and define business transaction 
boundaries. In addition, Server Components 222 are responsible for ensuring that business rules 
are honored during data access operations. 

A Server Component 222 performs data access operations on behalf of CCAs 208 or other 
components and participates in transactions spanning server components 222 by communicating 
with other server components 222 . The Server Component 222 is accessible by multiple front 
end personalities (e.g., Active Server Pages), and contains business logic designed to maintain 
the integrity of data in the database. 

Figure 2D is a flowchart showing the interactions between the CCA, the CCI, and the Server 
Component in accordance with one embodiment of the present invention. In step 242, a request 
is made to place client created data on the server database. In step 244, the data is transferred to 
the server component 222 utilizing a CCI 210. In step 246, the server component 222 stores the 
data in the server database. 



BUSINESS RULE PLACEMENT 



Overview 



The distribution of business rules across tiers of the application directly affects the robustness 
and performance of the system as a whole. Business rules can be categorized into the following 
sections: Relationships, Calculations, and Business Events. 
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Relationships between Business Objects 

Business Objects 207 are responsible for knowing other business objects 207 with which they 
are associated. 

Relationships between BOs 207 are built by the CCA 208 during the marshaling process. For 
example, when a CCA 208 builds an insurance claim BO 207, it will also build the collection of 
supplements if necessary. 

Calculated Business Data 

Business rules involving calculations based on business object 207 attributes are coded in the 
business objects 207 themselves. Participant Full Name is a good example of a calculated 
attribute. Rather than force the controllers to concatenate the first name, middle initial, and last 
name every time they wanted to display the full name, a calculated attribute that performs this 
logic is exposed on the business object. In this way, the code to compose the full name only has 
to be written once and can be used by many controllers 206. 

Another example of a calculated attribute is the display date of a repeating task. When a task 
with a repeat rule is completed, a new display date must be determined. This display date is 
calculated based on the date the task was completed, and the frequency of repetition defined by 
the repeat rule. Putting the logic to compute the new display date into the Task BO 207 ensures 
that it is coded only once. 

Responses to Business Events 

Business rules that relate to system events and involve no user interaction are enforced on the 
server components. 

Completion of a task is a major event in the system. When a task is completed, the system first 
ensures that the performer completing the task is added to the insurance claim. Then, after the 
task is marked complete in the database, it is checked to see if the task has a repeat rule. If so, 
another task is created and added to the database. Finally, the event component is notified, 
because the Task Engine may need to react to the task completion. 

Consider the scenario if the logic to enforce this rule were placed on the UI controller 206. 
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The controller 206 calls the Performer Component to see if the performer completing the task 
has been added to the insurance claim. If the performer has not been added to the claim, then the 
controller 206 calls the performer component again to add them. 

Next, the controller 206 calls the Task Component to mark the task complete in the database. If 
the task has a repeat rule, the controller 206 computes the date the task is to be redisplayed and 
calls the Task Component again to add a new task. Lastly, the controller 206 calls the Event 
Component to notify the Task Engine of the task completion. 



The above implementation requires five network round trips in its worst case. In addition, any 
other controller 206 or server component 222 that wants to complete a task must code this logic 
all over again. Enforcing this rule in the task server component 222 reduces the number of 
network round trips and eliminates the need to code the logic more than once. 

Responses to User Events 

All responses to user events are coordinated by the controller 206. The controller 206 is 
responsible for actions such as enabling or disabling controls on its form, requesting 
authorization from the security component, or making calls to the CCA 208. 

Authorization 

All logic for granting authorization is encapsulated inside the security component. Controllers 
206 and components 222 must ask the security component if the current user is authorized to 
execute certain business operations in the system. The security component will answer yes or no 
according to some predefined security logic. 

Summary 



Type of Business Rule 


Example 


Responsibility 


Maintaining relationships 
between BOs 


Claim keeps a collection of supplements 


Business Objects 


Building relationships 
between BOs 


CCA builds the claim's collection of 
supplements 


CCAs 


Calculated Business Data 


Participant calculates its full name 


Business Objects 


Responses to Business 
Events 


Task Component collaborates with other 
components 


Components 


Requesting Authorization 


Task Library controller asks the security 
component if the current user is allowed 
to access Task Library 


Controllers and 
Components 


Granting Authorization 


Security component determines whether 


Security Component 
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or not the current user can access Task 
Library 



WINDOW PROCESSING FRAMEWORK 

The Default Window Framework provides default window processing for each window 
contained within the system. This default processing aides the developer in developing robust, 
maintainable Uls, standardizes common processes (such as form initialization) and facilitates 
smooth integration with architecture services. 

Figure 3 shows the life cycle of a typical User Interface and the standard methods that are part of 
the Window Processing Framework 300. 

The Window Processing Framework 300 encompasses the following: 

Window Initialization 302; 

Window Save Processing 304; 

Window Control State Management 306; 

Window Data Validation 308; 

Window Shutdown Processing 310. 

Window Initialization Processing 302: After creating a controller 206 for the desired window, 
the App object 202 calls a set of standard initialization functions on the controller 206 before the 
form 204 is displayed to the user. Standardizing these functions makes the Uls more 
homogeneous throughout the application, while promoting good functional decomposition. 

Window Save Processing 304: Any time a user updates any form text or adds an item to a 
ListBox, the UI Controller 206 marks the form as "dirty". This allows the UI controller 206 to 
determine whether data has changed when the form closes and prompt the user to commit or lose 
their changes. 

Window Control State Management 306: Enabling and disabling controls and menu options 

is a very complex part of building a UI. The logic that modifies the state of controls is 

encapsulated in a single place for maintainability. 
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Window Data Validation 308: Whenever data changes on a form, validation rules can be 
broken. The controller is able to detect those changes, validate the data, and prompt the user to 



correct invalid entries. 



Window Shutdown Processing 310: The Window Shutdown framework provides a clear 
termination path for each UI in the event of an error. Thus reduces the chance of memory leaks 
and General Protection failures. 



Benefits 



Standardized Processing: Standardizing the window processing increases the homogeneity of 
the apphcanon. This ensures that all windows within the application behave in a consistent 
manner for the end users, making the application easier to use. It also shortens the learning 
curve for developers and increases maintainability, since all windows are coded in a consistent 



manner. 



S,mp.ified Development: Developers can leverage the best practices documented in the 
wmdow processing framework to make effective des.gn and codmg decisions. In addition a 
shell provides some "canned" code that gives developers a head start during the coding effort. 

Layered Architecture: Because several architecture modules provide standardized processing 
to each application window, the core logic can be changed for every system window by simply 
making modifications to a single procedure. 

Window Initialization 302 

To open a new window, the App Object 202 creates the target window's controller 206 and calls 
a senes of methods on the controller 206 to initialize it. The calling of these methods, 
ArchlnitClass, InitClass, InitForm, and ShowForm, is illustrated below. 
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ArchlnitClass 

The main purpose of the ArchlnitClass function is to tell the target controller 206 who is calling 
it. The App Object 202 "does the introductions" by passing the target controller 206 a reference 
to itself and a reference to the calling controller 206. In addition, it serves as a hook into the 
controller 206 for adding architecture functionality in the future. 

Public Sub ArchlnitClass (objApp As Object, objCallingCTLR As Object) 

* remember who called me 
Set m_objApp = objApp 

Set m_objCallingCTLR = objCallingCTLR 
End Sub 

InitClass 

This function provides a way for the App Object 202 to give the target controller 206 any data it 
needs to do its processing. It is at this point that the target controller 206 can determine what 
"mode" it is in. Typical form modes include, add mode, edit mode, and view mode. If the 
window is in add mode, it creates a new BO 207 of the appropriate type in this method. 

Public Sub InitClass (colPrevSelection As CArchCol lection) 

If colPrevSelection Is Nothing Then 

% no accounts were previously selected 

Set m colPrevSelection = New CArchCol lection 

Set m_colNewSelection = New CArchCol lection 

Else 

x some accounts may have already been selected 
Set m_colPrevSelection = colPrevSelection 
Set m_colNewSelection = colPrevSelection. Clone () 
End If 

Set m_colResults = New CArchCollection 

DetermineFormMode ( ) 
End Sub 

InitForm 

The InitForm procedure of each controller 206 coordinates any initialization of the form 204 
before it is displayed. Because initialization is often a multi-step process, InitForm creates the 
window and then delegates the majority of the initialization logic to helper methods that each 
have a single purpose, in order to follow the rules of good functional decomposition. For 
example, the logic to determine a form's 204 state based on user actions and relevant security 
restrictions and move to that state is encapsulated in the DetermineFormState method. 

Public Sub InitForm () 

' create my form 

Set m_frmCur rent Form = New frmAccount Search 
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XnitClfsnL 0 " State ° f ^ f ° rm b - ed « «*—t. I received in 

* enable/disable the appropriate controls 
DetermineFormState ( ) 



fill my form with data 
PopulateFormO 
End Sub 



PopulateForm 

PopulateForm is a private method responsible for filling the form with data dunng initialization 
t ,s ealled exactly once by the InitForm method. PopulateForm is used to fill combo boxes on a 
fonn 204, get the detailsofan object for an editing window, or display objects that have already 
been selected by the user, as in the following example. 



Private Sub PopulateFormO 

Dim acct As CAccount 
Dim item As GTListltem 

' creaie y an7Jr°T tS * lMy Selected »V the user 
create and add a Listltem for every Account i« 
selection collection every Account in the previous 

With frmCurrentForm.lvwResults. List Items 
- Clear 

For Each acct In m_colPrevSelection 

S T ^ = * Add( ' acct ' Nund)er ' acct. Number) 
item.Subltems(l) = acct. Name 

Next 
End With 
End Sub 



ShowForm 

The ShowForm method simply centers and displays the newly initialized form 204. 



Public Sub ShowForm () 

1 center my form 



„ lJf LUilll 

frmCurrentForm.Move (Screen. Width - frmCur rent Form. Width) / 2 
' display my form (SCreen - He1 ^ " ^CurrentForm. Height, /l 



display my form 

frmCurrentForm.Show vbModal 
End Sub 



Window Control State Management 306 

It is often necessary to enable or disable controls on a fonn 204 in response to user actions This 
sccuon descnbes the patterns employed by the Component Based Architecture for MTS 
(CBAM) to manage this process effectively. 
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Form Mode 

It is helpful to distinguish between form mode and form state. Form mode indicates the reason 
the form 204 has been invoked. Often, forms 204 are used for more than one purpose. A 
common example is the use of the same form to view, add, and edit a particular type of object, 
such as a task or a claim. In this case, the form's modes would include View, Add, and Update. 

The modes of a form 204 are also used to comply with security restrictions based on the current 
user's access level. For example, Task Library is a window that limits access to task templates 
based on the current user's role. It might have a Librarian mode and a Non-Librarian mode to 
reflect the fact that a non-librarian user cannot be allowed to edit task templates. In this way, 
modes help to enforce the requirement that certain controls on the form 204 remain disabled 
unless the user has a certain access level. 

It is not always necessary for a form 204 to have a mode; a form might be so simple that it would 
have only one mode - the default mode. In this case, even though it is not immediately 
necessary, it may be beneficial to make the form "mode-aware" so that it can be easily extended 
should the need arise. 

Form State 

A form 204 will have a number of different states for each mode, where a state is a unique 
combination of enabled/disabled, visible/invisible controls. When a form 204 moves to a 
different state, at least one control is enabled or disabled or modified in some way. 

A key difference between form mode and form state is that mode is determined when the 
controller 206 is initialized and remains constant until the controller 206 terminates. State is 
determined when the window initializes, but is constantly being reevaluated in response to user 
actions. 

Handling UI Events 

When the value of a control on the form 204 changes, it is necessary to reevaluate the state of the 
controls on the form (whether or not they are enabled/disabled or visible/invisible, etc.). If 
changing the value of one control could cause the state of a second control to change, an event 
handler is written for the appropriate event of the first control. 
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The following table lists common controls and the events that are triggered when their value 
changes. 



Control 


Event 


TextBox 


Change 


ComboBox 


Change 


ListBox 


Click 


CheckBox 


Click 


Option Button 


Click 



The event handler calls the DetermineFormState method on the controller 206. 
Setting the State of Controls 

It is essential for maintainability that the process of setting the state of controls be separate from 
the process for setting the values of those controls. The DetermineFormState method on the 
controller 206 forces this separation between setting the state of controls and setting their values. 

DetermineFormState is the only method that modifies the state of any of the controls on the form 
204. Because control state requirements are so complex and vary so widely, this is the only 
restriction made by the architecture framework. 

If necessary, parameters are passed to the DetermineFormState function to act as "hints" or 
"clues" for determining the new state of the form 204. For complex forms, it is helpful to 
decompose the DetermineFormState function into a number of helper functions, each handling a 
group of related controls on the form or moving the form 204 to a different state. 
Example 

The Edit/Add/View Task Window has three modes: Edit, Add, and View. In Add mode, 
everything on the form is editable. Some details will stay disabled when in Edit mode, since 
they should be set only once when the task is added. In both Add and Edit modes, the repeat rule 
may be edited. Enabling editing of the repeat rule always disables the manual editing of the 
task's due and display dates. In View mode, only the Category combo box and Private checkbox 
are enabled. 
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* Edit/Add/View Task Form 
Private Sub txtName_Change ( ) 

myController . DetermineFormState 
End Sub 



* Edit/Add/View Task Controller 
Public Sub DetermineFormState <) 
On Error Goto ErrorHandler 
Select Case m_nFormMode 

* In Edit Mode, enable only "editable" details and Repeat Rule 
editing if necessary 

Case cmFormModeEdit 

EnableAddDetails False 
EnableEditDetails True 
EnableViewDetails True 

If m_f rmCurrent Form. chkRepeteti veTask. Checked Then 
EnableEditRepeatRule True 
EnableEditDisplayDueDates False 

Else 

EnableEditRepeatRule False 
EnableEditDisplayDueDates True 
End If 

If m_nFormDirty Then EnableSave True Else EnableSave False 
% In Add Mode, enable all details and Repeat Rule editing if 
necessary 

Case cmFormModeAdd 

EnableAddDetails True 
EnableEditDetails True 
EnableViewDetails True 

If m_frmCurrent Form- chkRepeteti veTask. Checked Then 
EnableEditRepeatRule True 
EnableEditDisplayDueDates False 

Else 

EnableEditRepeatRule False 
EnableEditDisplayDueDates True 
End If 

If m_nFormDirty Then EnableSave True Else EnableSave False 
1 In View Mode, disable everything except a few details 
Case cmFormModeView 

EnableAddDetails False 
EnableEditDetails False 
EnableViewDetails True 
EnableEditRepeatRule False 
EnableEditDisplayDueDates False 
EnableSave False 
Case Else 
End Select 
Exit Sub 
ErrorHandler: 

* error handling 
End Sub 



* Edit/Add/View Task Controller 

Private Sub EnableAddDetails (bYesNo As Boolean) 

On Error Goto ErrorHandler 
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Enable or disable controls that 
task is being added. 

With frraCur rent Form 

-Name -Enabled « bYesNo 
.Description .Enabled = bYesNo 
-Type. Enabled = bYesNo 
. Level .Enabled = bYesNo 
. Source . Enabled = bYesNo 
End With 
Exit Sub 
ErrorHandler: 

1 error handling logic 
End Sub 
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should be available only when the 



Window Data Validation 308 

Window data validation is the process by which data on the window is examined for errors, 
inconsistencies, and proper formatting. It is important, for the sake of consistency, to implement 
this process similarly or identically in all windows of the application. 

Types of Validation 
Input Masking 

Input masking is the first line of defense. It involves screening the data (usually character by 
character) as it is entered, to prevent the user from even entering invalid data. Input masking 
may be done programmatically or via a special masked text box, however the logic is always 
located on the form, and is invoked whenever a masked field changes. 

Single-Field Range Checking 

Single-field range checking determines the validity of the value of one field on the form by 
comparing it with a set of valid values. Single-field range checking may be done via a combo 
box, spin button, or programmatically on the form, and is invoked whenever the range-checked 
field changes. 

Cross-Field Validation 

Cross-field validation compares the values of two or more fields to determine if a validation rule 
is met or broken, and occurs just before saving (or searching). Cross-field validation may be 
done on the Controller 206 or the Business Object 207, however it is preferable to place the logic 
on the Business Object 207 when the validation logic can be shared by multiple Controllers 206. 
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Invalid data is caught and rejected as early as possible during the input process. Input masking 
and range checking provide the first line of defense, followed by cross-field validation when the 
window saves (or searches). 

Single-Field Validation 

All single-field validation is accomplished via some sort of input masking. Masks that are 
attached to textboxes are used to validate the type or format of data being entered. Combo boxes 
and spin buttons may also be used to limit the user to valid choices. If neither of these are 
sufficient, a small amount of logic may be placed on the form's event handler to perform the 
masking functionality, such as keeping a value below a certain threshold or keeping apostrophes 
out of atextbox. 

Cross-Field Validation 

When the user clicks OK or Save, the form calls the IsFormData Valid on the controller to 
perform cross-field validation (e.g., verifying that a start date is less than an end date). If the 
business object 207 contains validation rules, the controller 206 may call a method on the 
business object 207 to make sure those rules are not violated. 



If invalid data is detected by the controller 206, it will notify the user with a message box and, if 
possible, the indicate which field or fields are in error. Under no circumstances will the window 
perform validation when the user is trying to cancel. 

Example 

* Generic Edit Form 
Private Sub cmdOK_Click () 

On Error Goto ErrorHandler 

* shut down if my data is valid. 

* saving/canceling will occur in my controller's QueryUnload function 
If IsFormDataValid Then Unload Me 

Exit Sub 
ErrorHandler: 

Err. Raise Err -Number 
End Sub 

Public Function IsFormDataValid ( ) As Boolean 

On Error Goto ErrorHandler 

* assume success 
IsFormDataValid = True 

* evaluate all validation rules 
With frmCurrentForm 
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% make sure start date is earlier than end date 
If . txtStartDate.Text > . txtEndDate . Text Then 

IsFormDataValid = False 

MsgBox cmMsglnvalidEndDate 

. txtEndDate . SetFocus 
Elself . . . 

* more validation rules 
End If 
End With 

Exit Function 
ErrorHandler : 

1 error handling logic 
End Function 



Window Save Processing 304 
Window "Save Processing" involves tracking changes to data on a fonn 204 and responding to 
save and cancel events initiated by the user. 

Tracking Changes to Form Data 

Each window within the CBAM application contains a field within its corresponding control 
object known as the dirty flag. The dirty flag is set to True whenever an end user modifies data 
within the window. This field is interrogated by the UI Controller 206 to deteimine when a user 
should be prompted on Cancel or if a remote procedure should be invoked upon window close. 

The application shell provides standard processing for each window containing an OK or Save 
button. 

Saving 

The default Save processing is implemented within the UI Controller 206 as follows: 

The UI Controller is Notified that the OK button has been clicked. Then the controller 206 
checks its Dirty Flag. If flag is dirty, the controller 206 calls the InterrogateForm method to 
retrieve data from the form 204 and calls a server component 222 to store the business object 
207 in the database. If the Dirty Flag is not set, then no save is necessary. The window is then 
closed. 
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Canceling 

When the user cancels a window, the UI Controller 206 immediately examines the Dirty Flag. If 
the flag is set to true, the user is prompted that their changes will be lost if they decide to close 
the window. 

Once prompted, the user can elect to continue to close the window and lose their changes or 
decide not to close and continue working. 



Window Shutdown Processing 310 

In the event of an error, it is sometimes necessary to shutdown a window or to terminate the 
entire application. It is critical that all windows follow the shutdown process in order to avoid 
15 the GPFs commonly associated with terminating incorrectly. Following is how the 
window/application is shutdown. 

Shutdown Scope 

The scope of the shutdown is as small as possible. If an error occurs in a controller 206 that does 
not affect the rest of the application, only that window is shut down. If an error occurs that 
20 threatens the entire application, there is a way to quickly close every open window in the 

application. The window shutdown strategy is able to accommodate both types of shutdowns. 

Shutdown 

In order to know what windows must be shut down, the architecture tracks which windows are 
open. Whenever the App Object 202 creates a controller 206, it calls its RegCTLR function to 
25 add the controller 206 to a collection of open controllers. Likewise, whenever a window closes, 
it tells the App Object 202 that it is closing by calling the App Object's 202 UnRegCTLR 
function, and the App Object 202 removes the closing controller 206 from its collection. In the 
case of an error, the App Object 202 loops through its collection of open controllers, telling each 
controller to "quiesce" or shutdown immediately. 
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GeneralErrorHandler 

The GeneralErrorHandler is a method in MArch.bas that acts as the point of entry into the 
architecture's error handling mechanism. A component or a controller will call the 
GeneralErrorHandler when they encounter any type of unexpected or unknown error. The 
general error handler will return a value indicating what the component or controller should do: 
(1) resume on the line that triggered the error (2) resume on the statement after the line that 
triggered the error (3) exit the function (4) quiesce (5) shutdown the entire application. 

ErrorHandler : 

Select Case CStr (Err .Number) 

% handle a search with no result error 
Case cmErrNoClaimTreeData 

MsgBox cmMsgNoResultsQuery, vblnf ormation 
frmCurrentForm. StatusBar. Panels (1) * cmNoResultsQuery 
'Sets mouse pointer back to default 
frmCurrentForm. MousePointer = vbDefault 
Case Else 

Dim nResumeCode As Integer 

nResumeCode = GeneralErrorHandler (objApp. obj Arch. AsMsqS true t 
cmCont roller, 

cmClassName, cmMethodName) 

Select Case CStr (nResumeCode) 
Case cmErrorResume 

Resume 
Case cmErrorResumeNext 

Resume Next 
Case cmErrorExit 

Exit Sub 
Case cmErrorQuiesce 

Quiesce 
Case Else 

objApp . Shutdown 
End Select 
End Select 
35 End Sub 

In order to prevent recursive calls the GeneralErrorHandler keeps a collection of controllers that 
are in the process of shutting down. If it is called twice in a row by the same controller 206, it is 
able to detect and short-circuit the loop. When the controller 206 finally does terminate, it calls 
40 the UnRegisterError function to let the GeneralErrorHandler know that it has shut down and 
removed from the collection of controllers. 
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Shutdown Process 

After being told what to do by the GeneralErrorHandler, the controller 206 in error may try to 
execute the statement that caused the error, proceed as if nothing happened, exit the current 
function, call its Quiesce function to shut itself down, or call the Shutdown method on the App 
5 Object 202 to shut the entire application down. 



10 

Additional Standard Methods 

Searching 

Controllers 206 that manage search windows have a public method named Find<Noun>s where 
<Noun> is the type of object being searched for. This method is called in the event handler for 
1 5 the Find Now button. 

Saving 

Any controller 206 that manages an edit window has a public method called Save that saves 
changes the user makes to the data on the form 204. This method is called by the event handlers 
for both the Save and OK buttons (when/if the OK button needs to save changes before closing). 

20 Closing 

A VB window is closed by the user in several ways: via the control-box in upper left corner, the 
X button in upper right corner, or the Close button. When the form closes, the only method that 
will always be called, regardless of the way in which the close was initiated, is the form's 204 
QueryUnload event handler. 

25 

Because of this, there cannot be a standard Close method. Any processing that must occur when 
a window closes is to be done in the QueryUnload method on the controller 206 (which is called 
by the form's QueryUnload event handler). 



30 



The VB statement, Unload Me, appears in the Close button's event handler to manually initiate 
the unloading process. In this way, the Close button mimics the functionality of the control box 
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and the X button, so that the closing process is handled the same way every time, regardless of 
how the user triggered the close. The OK button's event handler also executes the Unload Me 
statement, but calls the Save method on the controller first to save any pending changes. 



BUSINESS OBJECTS 

Business Objects 207 are responsible for containing data, maintaining the integrity of that data, 
and exposing functions that make the data easy to manipulate: Whenever logic pertains to a 
single BO 207 it is a candidate to be placed on that BO. This ensures that it will not be coded 
once for each controller 206 that needs it. Following are some standard examples of business 
object logic. 

Business Logic: Managing Life Cycle State 

Overview 

The "state" of a business object 207 is the set of all its attributes. Life cycle state refers only to a 
single attribute (or a small group of attributes) that determine where the BO 207 is in its life 
cycle. For example, the life cycle states of a Task are Open, Completed, Cleared, or Error. 
Business objectives usually involve moving a BO toward its final state (i.e., Completed for a 
Task, Closed for a Supplement, etc.). 

Often, there are restrictions on a BO's movement through its life cycle. For example, a Task 
may only move to the Error state after first being Completed or Cleared. BOs provide a 
mechanism to ensure that they do not violate life cycle restrictions when they move from state to 
state. 

Approach 

A BO 207 has a method to move to each one of its different life cycle states. Rather than simply 
exposing a public variable containing the life cycle state of the task, the BO exposes methods, 
such as Task.Clear(), Task.CompleteO, and Task.MarklnError(), that move the task a new state. 
This approach prevents the task from containing an invalid value for life cycle state, and makes it 
obvious what the life cycle states of a task are. 
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Example 

' CTask Business Object 
Public Sub MarklnError () 

On Error Goto ErrorHandler 

5 

Select Case m_nLif eCycleState 

1 move to error only if I've already been completed or cleared 
Case cmTaskCompleted, cmTaskCleared 
m_nLif eCycleState = cmTasklnError 
10 * otherwise, raise an error 

Case Else 

Err . Raise cmErrlnvalidLif eCycleState 
End Select 
Exit Sub 
1 5 ErrorHandler : 

Err. Raise Err. Number 
End Sub 



20 

Business Logic: Operating on Groups of Business Objects 

Overview 

Sometimes, a BO 207 acts as a container for a group of other BOs. This happens when 
performing operations involving multiple BOs. For example, to close, a claim ensures that it has 
25 no open supplements or tasks. There might be a method on the claim BO - CanCloseO - that 
evaluates the business rules restricting the closing of a claim and return true or false. Another 
situation might involve retrieving the open tasks for a claim. The claim can loop through its 
collection of tasks, asking each task if it is open and, if so, adding it to a temporary collection 
which is returned to the caller. 

30 Example 

1 Claim Business Object 

% Error handling omitted for clarity 

Public Function CanCloseO As Boolean 

CanClose = HasOpenTasks ( ) And HasOpenSupplements ( ) 
35 End Function 

Public Function HasOpenTasks () As Boolean 

% assume that I have open tasks 
HasOpenTasks = True 

40 1 loop through all my tasks and exit if I find one that is open 

Dim task As CTask 
For Each task In m_colTasks 

If task. IsOpen ( ) Then Exit Function 
Next task 

45 * I must not have any open tasks 

HasOpenTasks = False 
End Function 
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Public Function HasOpenSupplements ( ) As Boolean 

assume that I have open supplements 
HasOpenSupplements = True 

* loop through all my supplements and exit if I find one that is open 

Dim supp As CSupplement 

For Each supp in m_colSupplements 

If supp.IsOpenO Then Exit Function 
Next supp 

HasOpenSupplements = False 
10 End Function 

Public Function GetOpenTasks () As Collection 
Dim task As CTask 
Dim colOpenTasks As Collection 
15 For Each task In m_colTasks 

If task.Is0pen() Then colOpenTasks .Add task, task. Id 
Next task 

Set GetOpenTasks = colOpenTasks 
End Function 

20 

Business Object Structures 

Overview 

When a BO 207 is added or updated, it sends all of its attributes down to a server component 222 
25 to write to the database. Instead of explicitly referring to each attribute in the parameter list of 
the functions on the CCA 208 and server component 222 , all the attributes are sent in a single 
variant array. This array is also known as a structure. 

Approach 

Each editable BO 207 has a method named AsStruct that takes the object's member variables 
30 and puts them in a variant anay. The CCA 208 calls this method on a BO 207 before it sends the 
BO 207 down to the server component 222 to be added or updated. The reason that this is 
necessary is that, although object references can be passed by value over the network, the objects 
themselves cannot. Only basic data types like Integer and String can be sent by value to a server 
component 222 . A VB enumeration is used to name the slots of the structure, so that the server 
35 component 222 can use a symbolic name to access elements in the array instead of an index. 

Note that this is generally used only when performing adds or full updates on a business object 
207. 

In a few cases, there is a reason to re-instantiate the BO 207 on the server side. The FromStnict 
40 method does exactly the opposite of the AsStruct method and initializes the BO 207 from a 
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variant array. The size of the structure passed as a parameter to FromStruct is checked to 
increase the certainty that it is a valid structure. 



When a BO 207 contains a reference to another BO 207, the AsStruct method stores the primary 
key of the referenced BO 207. For example, the Task structure contains a Performerld, not the 
performer BO 207 that is referenced by the task. When the FromStruct method encounters the 
Performerld in the task structure, it instantiates a new performer BO and fills in the ID, leaving 
the rest of the performer BO empty. 

Example 

% CTask Business Object 

* enumeration of all task attributes 
Public Enum TaskAt tributes 

cmTaskld 
cmTaskName 

cmTaskDescription 
End Enum 

% all task attributes declarations here 

* all setter and getter functions here 

Public Function AsStruct () As CTask 

On Error Goto ErrorHandler 

% create and fill structure 

Dim vStruct (cmTaskNumOf Attributes - 1) As Variant 

vSt rue t (cmTaskld) = m_vld 

vStruct (cmTaskName) = m_sName 

vStruct (cmTaskPerf ormerld) = m_vPer former Id 

vStruct (cmTaskDescription) » msDescription 

AsStruct = vStruct 

Exit Function 
ErrorHandler: 

Err. Raise Err. Number 
End Function 

Public Sub FromStruct (vStruct As Variant) 

On Error Goto ErrorHandler 

* check size of vStruct 

If Ubound (vStruct) <> (cmTaskNumOf Attributes - 1) Then Err. Raise 
cmErrlnvalidParameters 

% update my values from the structure 
m_vld = vStruct (cmTaskld) 
m_sName = vStruct (cmTaskName) 
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m_vPerformer.ld = vStruct (cmTaskPerf ormerld) 

m_sDescription = vStruct (craTaskDescription) 

Exit Sub 
ErrorHandler : 

Err. Raise Err. Number 
End Sub 



Cloning Business Objects 

Overview 

Often a copy of a business object 207 is made. Cloning is a way to implement this kind of 
functionality by encapsulating the copying process in the BO 207 itself. Controllers 206 that 
need to make tentative changes to a business object 207 simply ask the original BO 207 for a 
clone and make changes to the clone. If the user decides to save the changes, the controller 206 
ask the original BO to update itself from the changes made to the clone. 

Approach 

Each BO 207 has a Clone method to return a shallow copy of itself A shallow copy is a copy 
that doesn't include copies of the other objects that the BO 207 refers to, but only a copy of a 
reference to those objects. For example, to clone a task, it does not give the clone a brand new 
claim object; it gives the clone a new reference to the existing claim object. Collections are the 
only exception to this rule - they are always copied completely since they contain references to 
other BOs. 



Each BO 207 also has an UpdateFromClone method to allow it "merge" a clone back in to itself 
by changing its attributes to match the changes made to the clone. 

Example 

x CTask Business Object 

Public Function Clone () As CTask 

On Error Goto ErrorHandler 

* create clone object 
Dim tskClone As CTask 
Set tskClone = New CTask 

* fill clone with my data 
With tskClone 

. Id = m_vld 

-Name = m_sName 

-Perf ormerld » m_vPerf ormerld 

Set .Performer = m__prf Performer 
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.Description = msDescript ion 
End With 

Set Clone = tskClone 

Exit Function 
ErrorHandler : 

Err. Raise Err. Number 
End Function 

Public Sub UpdateFromClone ( tskClone As CTask) 
On Error Goto ErrorHandler 

1 set my values equal to the clone's values 
With tskClone 

m_vld = . ID 

m_sName = .Name 

m_vPerformerId = .Performer Id 

Set m_prf Performer = .Performer 

m_sDescription = .Description 
End With 

Exit Sub 
ErrorHandler : 

Err. Raise Err. Number 
End Sub 



Half-Baked Business Objects 

Overview 

BOs 207 occasionally are filled only half-full for performance reasons. This is done for queries 
involving multiple tables that return large data sets. Using half-baked BOs 207 can be an error 
prone process, so it is essential that the half-baking of BOs are carefully managed and contained. 

In most applications, there are two kinds of windows - search windows and edit/detail windows. 
Search windows are the only windows that half-bake BOs 207. Generally, half-baking only is a 
problem when a detail window expecting a fully-baked BO receives a half-baked BO from a 
search window. 

Approach 

Detail windows refresh the BOs 207 they are passed by the search windows, regardless of 
whether or not they were already fully-baked. This addresses the problems associated with 
passing half-baked BOs and also helps ensure that the BO 207 is up-to-date. 
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This approach requires another type of method (besides Get, Add, Update, and Delete) on the 
CCA 208: a Refresh method. This method is very similar to a Get method (in fact, it calls the 
same method on the server component) but is unique because it refreshes the data in objects that 
are already created. The detail window's controller 206 calls the appropriate CCA 208 passing 
the BO 207 to be refreshed, and may assume that, when control returns from the CCA 208, the 
BO 207 will be up-to-date and fully-baked. 

This is may not be necessary if two windows are very closely related. If the first window is the 
only window that ever opens the second, it is necessary for the second window to refresh the BO 
207 passed by the first window if it knows that the BO 207 is baked fully enough to be used. 



CCAs 



CCAs 208 are responsible for transforming data from row and columns in a recordset to business 
objects 207, and for executing calls to server components 222 on behalf of controllers 206. 

Retrieving Business Objects 

Overview 

After asking a component to retrieve data, the CCA 208 marshals the data returned by the 
component into business objects 207 that are used by the UI Controller 206. 

Approach 

The marshaling process is as follows: 

CCAs 208 call GetRows on the recordset to get a copy of its data in a variant array in order to 
release the recordset as soon as possible. A method exist to coordinate the marshaling of each 
recordset returned by the component. 

Only one recordset is coordinated in the marshaling process of a single method. A method exist 
to build a BO from a single row of a recordset. This method is called once for each row in the 
recordset by the marshaling coordination method. 
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Example 

1 Task CCA 

Public Function GetAllTasks ( ) As Collection 
On Error Goto ErrorHandler 

* call a helper method to retrieve tasks 
Dim vRows As Variant 

vRows = RetrieveAllTasks 

Dim i As Integer 

Dim task As CTask 

Dim colTasks As Collection 

Set colTasks = New Collection 

1 vRows is dimmed as column, row. Loop til I run out of rows. 
For i = 0 To Ubound (vRows , 2) 

* build BO using helper method 

Set task = BuildTaskFromRow(vRows , i) 

* add to collection with ID as the key 
colTasks. Add task, task. Id 

Next i 

Set MarshalTasks = colTasks 

Exit Function 
ErrorHandler : 

Err. Raise Err. Number 
End Function 

Private Function RetrieveAllTasks () As Variant 

On Error Goto ErrorHandler 

* call my component and get a recordset full of all tasks 
Dim rs As ADOR . Recordset 

Set rs = tskComp. GetAllTasks 0 

* get data in variant array from the recordset 
GetAllTasks = rs.GetRows 

* release the recordset ASAP 
rs .Close 

Set rs = Nothing 

Exit Function 
ErrorHandler : 

Err. Raise Err. Number 
End Function 

Private Function BuildTaskFromRow (vRows As Variant, nCurrentRow As 
Integer, _ 

Optional task As CTask) As CTask 

On Error Goto ErrorHandler 

1 create task if it wasn't passed 
If task Is Nothing Then Set task = New CTask 
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% fill task with data 

With task 

.Id = vRows(0, nCurrentRow) 
.Name » vRows(l # nCurrentRow) 
.Performerld = vRows(2, nCurrentRow) 

.Description = vRows(32, nCurrentRow) 
End With 

Set BuildTaskFromRow = task 

Exit Function 
ErrorHandler : 

Err. Raise Err. Number 
End Function 



Refreshing Business Objects 

Overview 

The logic to refresh BOs 207 is very similar to the logic to create them in the first place. A 
"refresh" method is very similar to a "get" method, but must use BOs 207 that already exist 
when carrying out the marshalling process. 

Example 

* Task CCA 

Public Sub RefreshTask(task As CTask) 

On Error Goto ErrorHandler 

* call a helper method to retrieve tasks 
Dim vRow As Variant 

vRow = RetrieveTaskWithld(task.Id) 

BuildTaskFromRow vRow, i, task 

Exit Sub 
ErrorHandler: 

Err. Raise Err. Number 
End Sub 

Private Function RetrieveTaskWithId(vld As Variant) As Variant 
On Error Goto ErrorHandler 

call my component and get a recordset full of all tasks 
Dim rs As ADOR. Recordset 
Set rs = tskComp.GetTaskWithld(vld) 

• get data in variant array from the recordset 
RetrieveTaskWithld = rs.GetRows 



* release the recordset ASAP 
rs. Close 

Set rs = Nothing 



Exit Function 
ErrorHandler: 
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Err. Raise Err. Number 
End Function 



Adding Business Objects 

Overview 

Controllers 206 are responsible for creating and populating new BOs 207. To add a BO 207 to 
the database, the controller 206 must call the CCA 208, passing the business object 207 to be 
added. The CCA 208 calls the AsStruct method on the BO 207, and pass the BO structure down 
to the component to be saved. It then updates the BO 207 with the ID and timestamp generated 
by the server. Note the method on the CCA 208 just updates the BO 207. 

Example 

% Task CCA 

Public Sub AddTask (task As CTask) 
On Error Goto ErrorHandler 

* call component to add task passing a task structure 

Dim vldAndTimestamp As Variant ^ 
vldAndTimestamp = tskComp .AddTask (task. AsStruct () ) 

* update ID and Timestamp on task 
task. Id vldAndTimestamp (0) 

task. Timestamp = vldAndTimestamp (1) 

Exit Sub 
ErrorHandler: 

Err. Raise Err. Number 
End Sub 



Updating Business Objects 

Overview 

The update process is very similar to the add process. The only difference is that the server 
component only returns a timestamp, since the BO already has an ID. 

Example 

x Task CCA 

Public Sub UpdateTask(task As CTask) 

On Error Goto ErrorHandler 

* call component to update task passing a task structure 
Dim iTimeStamp As Long 

iTimeStamp = tskComp. AddTask (task. AsStruct () ) 

* update Timestamp on task 
task. TimeStamp = ITimeStamp 
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Exit Sub 
ErrorHandler: 

Err. Raise Err. Number 
End Sub 

5 

Deleting Business Objects 

Deleting Overview 

Like the add and the update methods, delete methods take a business object 207 as a parameter 
and do not have a return value. The delete method does not modify the object 207 it is deleting 
10 since that object will soon be discarded. 

Example 

y Task CCA 

Public Sub DeleteTask(task As CTask) 

On Error Goto ErrorHandler 

15 

call component to update task passing a the ID and Timestamp 
tskComp.DeleteTask task. Id, task. TimeStamp 
Exit Sub 
ErrorHandler: 
20 Err. Raise Err. Number 

End Sub 



25 



30 



SERVER COMPONENT 

Server components 222 have two purposes: enforcing business rules and carrying out data 
access operations. They are designed to avoid duplicating logic between functions. 

Designing for Reuse 

Enforcing Encapsulation 

Each server component 222 encapsulates a single database table or a set of closely related 
database tables. As much as possible, server components 222 select or modify data from a 
35 single table. A component occasionally selects from a table that is "owned" or encapsulated by 
another component in order to use a join (for efficiency reasons). A server component 222 often 
collaborates with other server components to complete a business transaction. 
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Portioning Logic between Multiple Classes 

If the component becomes very large, it is split into more than one class. When this occurs, it is 
divided into two classes - one for business rules and one for data access. The business rules 
class implements the component's interface and utilizes the data access class to modify data as 
needed. 



Example 

Private Function MarkTasklnError { vMsg As Variant, 

vTaskld As Variant, 
ITimestamp As Variant, 
sReason As String) As Long 

On Error GoTo ErrorHandler 

Const cmMethodName = "MarkTasklnError" 

1 set the SQL statement 

Dim sSQL As String 

sSQL = cmSQLMarkTasklnError 

% get a new times tamp 
Dim lNewTimeStamp As Long 
lNewTimeStamp = GetTimeStamp ( ) 

* create and fill a collection of arguments to be merged with 
% the SQL by the ExecuteQuery method 

Dim colArgs As CCollection 
Set colArgs = New CCollection 
With colArgs 

.Add lNewTimeStamp 

.Add cmDBBooleanTrue 

.Add s Reason 

.Add vTaskld 

.Add ITimestamp 
End With 

* run the SQL and set my return value 

ExecuteQuery vMsg, cmUpdate, sSQL, colArguments : =colArgs 
MarkTasklnError = lNewTimeStamp 

1 tell MTS I'm done 
GetObjectContext . SetComplete 
Exit Function 

ErrorHandler: 

* do error handling here 
End Function 
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ERROR HANDLING 
General Information 

With the exception of "Classjnitiatize", "Class_Terminate", and methods called within an error 
handler, every function or subroutine has a user defined 'On Error GoTo* statement. The first 
line in each procedure is: On Error GoTo ErrorHandler. A line near the end of the procedure is 
given a label "ErrorHandler". (Note that because line labels in VB 5.0 have procedure scope, 
each procedure can have a line labeled "ErrorHandler"). The ErrorHandler label is preceded by 
a Exit Sub or Exit Function statement to avoid executing the error handling code when there is 
no error. 

Errors are handled differently based on the module's level within the application (i.e., user 
interface modules are responsible for displaying error messages to the user). 

All modules take advantage of technical architecture to log messages. Client modules that 
already have a reference to the architecture call the Log Manager object directly. Because server 
modules do not usually have a reference to the architecture, they use the LogMessage() global 
function complied into each server component. 
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Any errors that are raised within a server component 222 are handled by the calling UI 
controller 206. This ensures that the user is appropriately notified of the error and that business 
errors are not translated to unhandled fatal errors. 

All unexpected errors are handled by a general error handler function at the global Architecture 
module in order to always gracefully shut-down the application. 

Server Component Errors 
The error handler for each service module contains a Case statement to check for all anticipated 
errors. If the error is not a recoverable error, the logic to handle it is first tell MTS about the 
error by calling GetObjectContext.SetAbort(). Next, the global LogMessage0 function is called 
to log the short description intended for level one support personnel. Then the LogMessageQ 
function is called a second time to log the detailed description of the error for upper level support 
personnel. Finally, the error is re-raised, so that the calling function will know the operation 
failed. 

A default Case condition is coded to handle any unexpected errors. This logs the VB generated 
error then raises it. A code sample is provided below: 

Following is an example of how error handling in the task component is implemented when an 
attempt is made to reassign a task to a performer that doesn't exist. Executing SQL to reassign a 
task to a non-existent performer generates a referential integrity violation error, which is trapped 
in this error handler: 

'Class Declarations 

Private Const cmClassName = "CTaskComp" 

Public Sub ReassignTaskU) 

On Error GoTo ErrorHandler 

Private Const cmMethodName = "ReassignTask" 

Private Const cmErrReassignTask = "Could not reassign task." 

* logic to reassign a task 

GetObject Context . SetCoraplete 
Exit Sub 

ErrorHandler: 

Dim sShortDescr As String 
sShortDescr = cmErrReassignTask 
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log short description as warning 
LogMessage vMsg, Err. Number, cmSeverityWarning , cmClassName, 
cmMethodName, sShortDescr 

Dim sLongDescr As String 
Select Case Err. Number 

Case cmErrRef IntegrityViolation 
GetObjectContext.SetAbort 

sLongDescr = "Referential integrity violation - tried » 

& "to reassign task to a non-existant performer. « ~ 
& "Association ID: " & sAssnld 
& "Association Type 
& "Old Performer Id 
& "New Performer Id 



8c sAssnType _ 
& sOldPerformerld 
& sNewPerformerld 
log long description as severe 
LogMessage vMsg, Err. Number, cmSeveritySevere, cmClassName, 



cmMethodName, _ 

sLongDescr 
Err. Raise Err. Number 

* more error handling 

Case Else 

let architecture handle unanticipated error 
Dim nResumeCode As Integer 

nResumeCode = General Er rorHandler {vMsg, cmServer, cmClassName 
cmMethodName) 

Select Case nResumeCode 
Case cmError Resume 

Resume 
Case cmErrorResumeNext 

Resume Next 
Case cmErrorExit 

Exit Sub 
Case Else 

GetObjectContext .Abort 
Err. Raise Err. Number 
End Select 
End Select 
End Sub 



CCAs, CCIs, Business Objects, and Forms 

All CCFs, CCA's, Business Objects, and Forms raise any error that is generated. A code samole 
is provided below: ~ F 

Sub SubName () 

On Error GoTo ErrorHandler 
<the procedure's code hero 



Exit Sub 
ErrorHandler: 

Err. Raise Err. Number 
End Sub 
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User Interface Controller Errors 

The user interface controllers 206 handle any errors generated and passed up from the lower 
levels of the application. UI modules are responsible for handling whatever errors might be 
raised by server components 222 by displaying a message box to the user. 

Any error generated in the UTs is also displayed to the user in a dialog box. Any error initiated 
on the client is logged using the LogMessage() procedure. Errors initiated on the server will 
already have been logged and therefore do not need to be logged again. 

All unexpected errors are trapped by a general error method at the global architecture module. 
Depending on the value returned from this function, the controller may resume on the statement 
that triggered the error, resume on the next statement, call its Quiesce function to shut itself 
down, or call a Shutdown method on the application object to shutdown the entire application. 

No errors are raised from this level of the application, since controllers handle all errors. A code 
sample of a controller error handler is provided below: 

'Class Constants 

Private Const cmClassName As String = M <ComponentName>" 

Sub SubName ( ) 

On Error GoTo ErrorHandler 

Const cmMethodName As String = "<MethodName> n 

<the procedure's code here> 

Exit Sub 

ErrorHandler: 

Select Case CStr (Err .Number) 
Case ... 

'display the error to the user 

% perform any necessary logic 

Exit Sub (or Resume, or Resume Next) 



Case Else 

Dim nResumeCode As Integer 
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nResumeCode = General ErrorHandl er (vMsg, cmController, 
cmClassName, cmMethodName) 

Select Case CStr (nResumeCode ) 
Case cmError Resume 

Resume 
Case cmErrorResumeNext 

Resume Next 
Case cmErrorExit 

Exit Sub 
Case cmErrorQuiesce 

Quiesce 
Case Else 

objApp. SHUTDOWN 
End Select 
End Select 
End Sub 



LOCALIZATION 



The CBAM application is constructed so that it can be localized for different languages and 
countries with a minimum effort or conversion. 



Requirements and Scope 



The CBAM architecture provides support for certain localization features: 
Localizable Resource Repository; 
Flexible User Interface Design; 
Date Format Localization; and 

Exposure of Windows Operation System Localization Features. 



Localization Approach Checklist 



Localization Feature 


Supported via 

Architecture 

Service 


Supported via 

Architecture 

API's 


Best Practices and 
Assumptions* 


Language Code 
(Locale Identifier) 








Time Zones 








Date/Time 








Name 






s 


Telephone Numbers 








Functions to Avoid 
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Weights and Measures 








Money 








Addresses/Address Hierarchies 








Menus, Icons, Labels/Identifiers 
on Windows 








Messages/ Dialogs 








String Functions, Sort Order and 
String Comparison 








Code Tables 








Drop-Down Lists 








Form & Correspondence 
Templates 








Online and Printed Documentation 








Database (DB2) 








3 rd Party Controls 
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Localizable Literals Repository 



The CBAM application has an infrastructure to support multiple languages. The architecture 
acts as a centralized literals repository via its Codes Table Approach. 

The Codes Tables have localization in mind. Each row in the codes table contains an associated 
language identifier. Via the language identifier, any given code can support values of any 
language. 

Flexible Interface 400 

Flexible user interface 400 and code makes customization easy. The Figure 4 illustrates how 
different languages are repainted and recompiled. For example, both a English UI 404, and a 
French UI 406 are easily accommodated. This entails minimal effort because both UIs share the 
same core code base 402. Updates to the UIs are merely be a superficial change. 

Generic graphics are used and overcrowding is avoided to create a user interface which is easy to 
localize. 
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Data Localization 

Language localization settings affect the way dates are delayed on UTs (user interfaces) The 
default system disp.ay format is different for Afferent Language/Countries. For Example: 
English (United States) displays "mm/dd/yy" (e.g., "05/1 6/98") 
English (United Kingdom) displays "dd/mm/yy" (e.g., "16/05/98"). 

Represent inventions ^'s employ a number of third-party date controls induding 5^ 
Calendar Widgets (from Sheridan Software) which allow developers to set predefined input 
masks for dates (via the controls' Property Pages; the property in this case is "Mask"). 

Although the Mask property can be manipulated, the default setting ,s preferably accepted (the 
default setting for Mask is "0 - System Default"; it is set at design time). Aceepting the default 
system settmgs eliminates the need to code for multiple locales (with some possible exceptions) 
does not mterfere with intrinsic Visual Basic functions such as DateAdd, and al.ows dates to be ' 
formatted as strings for use in SQL. 

The test program illustrated below shows how a date using the English (United Kingdom) 
default system date format is reformatted to a user-defined format (in this case, a stnng constant 
for use with DB2 SQL statements): 

Const cmDB2Da t eAndTime = ••m m -dd-yyyy-h. mra . ss .. 

Private Sub cndConvToDB2_Click () 

Dim sDB2Date As String 

sDB2Date = Format $ (SSDateCombol .Date 

cmDB2DateAndTime ) 

txtDB2String.Text = sDB2Date 
End Sub 



Leverage Windows Operation System 

The CBAM architecture exposes interface methods on the RegistryService object to access 
locale specific values which are set from the control panel. 

The architecture exposes an API from the RegistrySen.ee object which ailows access to all of 
the information available in the control panel. Shown below is the signature of the API- 
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GetRegional Info (Info As Regionallnfo) As String 

Where Regionallnfo can be any of the values in the table below: 



Regionallnfo Values 



CmLanguageld 
Cm Language Local ized 
CmLanguage Eng 1 i sh 
Cm Langu ageAbb r 
CmLanguageNat ive 
CraCountryld 
CraCount ryLoca 1 i zed 
CmCount ry Eng 1 i s h 
QnCount ryAbb r 
CmCount ry N at ive 
CmLanguageDe fault Id 
CmCount ryDef au 1 1 Id 



CmDTDateSeparator 
CmDTT ime Sepa r a t or 
OnDTShort Date Format 
CmLDTongDate Format 
CmDTT imeFormat 
CmDTDat e Forma t Orde r ing 
CmDTLongDateOrdering 
CmDTT ime Format Spe c i f ie r 
CmDTCentu ry Format Spec i f i e r 
CmDTT iraeWithLeading Zeros 
CmDTDayWithLeadingZeros 
CmDTMonthW i t hLeadingZe ros 
CmDTDes ignator AM 
CmDTDes ignator PM 



cmDayLongNaraeMonday 
cmDayLongNaraeTuesday 
cmDayLongName Wednesday 
cmDayLongNameThursday 
cmDayLongName Friday 
cmDay LongNameS a t u r da y 
cmDayLongName Sunday 
cmDayAbbrNameMonday 
cmDayAbb rNameTuesday 
cmDayAbbrNameWednesday 
cmDayAbb rNameThursday 
cmDayAbb rName Fr iday 
cmDayAbb rNameSa turd ay 
cmDayAbb rNameSunday 



craMonthLongNameJan 
cmMon t hLongName Feb 
cmMont hLongNameMa r 
cmMonthLongNaraeApr 
cmMont hLongNameMay 
cmMonthLongNameJun 
cmMon t hLongName Ju 1 
cmMonthLongNameAug 
cmMonthLongNameSep 
cmMon t h LongNameOc t 
cmMon thLong Name Nov 
cmMont hlfOngNameDe c 
cmMon t hAbb rNarae Jan 
cmMonthAbbrName Feb 
cmMont hAbb rNameMa r 
cmMont hAbb rNameAp r 
cmMonthAbbrNameMay 
cmMont hAbb rNarae Jun 
cmMon t hAbb rNameJul 
cmMont hAbbr NameAug 
cmMont hAbb rName Sep 
cmMonthAbbrNameOct 
cmMonthAbbrNameNov 
cmMonthAbbrNameDec 



Get Regionallnfo Example: 

Private Sub Command lClick () 

MsgBox "This is the language id for English: ■ & 

GetRegional Inf o (cmLanguageld) 
End Sub 



Logical Unit of Work 

The Logical Unit of Work (LUW) pattern enables separation of concern between UI Controllers 
206 and business logic. 

Overview 

Normally, when a user opens a window, makes changes, and clicks OK or Save, a server 
component 222 is called to execute a transaction that will save the user's changes to the 
database. Because of this, it can be said that the window defines the boundary of the transaction, 
since the transaction is committed when the window closes. 
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The LUW pattern is useful when database transactions span windows. For example, a user 
begins ed,t,ng data on one window and then, without saving, opens another window and begins 
edtttng data on that window, the save process involves multiple windows. Neither window 
controller 206 can manage the saving process, since data from both windows must be saved 
part of an indivisible unit of work. Instead, a LUW object is introduced to manage the saving 
process. 

The LUW acts as a sort of "shopping bag". When a controller 206 modifies a business obj ect 
207, ,t puts it in the bag to be paid for (saved) later. It might give the bag to another controller 
206 to fimsh the shopping (modify more objects), and then to a third controller who pays (asks 
the LUW to initiate the save). 

Approach 

Controllers 206 may have different levels of LUW "awareness": 
Requires New: always creates a new LUW; 

Eeguireg: requires an LUW, and creates a new LUW only if one is not passed by the calling 
controller; 

^auh^Emm: quires an LUW, but does not create a new LUW if one is not passed by the 
calling controller. Raises an error if no LUW is passed; and 
Not Supported: is not capable of using an LUW. 

Controllers 206 that always require a new LUW create that LUW in their ArchlnitClass function 
during mitialization. They may choose whether or not to involve other windows in their LUW 
If U ,s des,rable for another window to be involved in an existing LUW, the controller 206 that 
owns the LUW passes a reference to that LUW when it calls the App Object 202 to open the 
second window. Controllers 206 that require an LUW or require an existing LUW accept the 
LUW as a parameter in the ArchlnitClass function. 

LUWs contain all the necessary logic to persist their "contents" - the modified BOs 207 They 
handle calling methods on the CCA 208 and updating the BOs 207 with new IDs and/or 
timestamps. 
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ARCHITECTURE API HIERARCHY 

Following is an overview of the architecture object model, including a description of each 
method and the parameters it accepts. Additional sections address the concepts behind specific 
5 areas (code caching, message logging, and data access) in more detail. 

Arch Object 

Figure 5 depicts the current properties on the Arch Object 200. 

10 The following are APIs located on the Arch Object 200 which return either a retrieved or created 

instance of an object which implements the following interfaces: 

CodesMan() 500; 

TextManO 502; 

IdManQ 504; 
15 RegManO 506; 

LogManO 508; 

ErrMan()510; 

UserMan()512; and 

SecurityMan()514. 

20 

AsMsgStructQ 

This method on the Arch Object returns a variant structure to pass along a remote message. 

25 Syntax: 

Public Function AsMsgStruct () As Variant 
End Function 

Example: 

30 Dim vMsg As Variant 

vMsg = objArch. AsMsgStruct 

CodesMan 

35 

The following are APIs located on the interface of the Arch Object 200 named CodesMan 500: 
CheckCacheFreshness(); 
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FillControKctlControl, nCategory, nFillType, fnCodeStatus], [coIAssignedCodes]); 

FilterCodes(coIAHCodes, nCodeStatus); 

GetCategoryCodes(nCategory); 

GetCodeObject(nCategory, sCode); 

GetResourceString(lStringld); 

GetServerDate(); 

RefreshCache(); 

RemoveVaIidDates(sCode, coIPassedlnAssignedCodes); and 
SetServerDate(dtServerDate). 

CheckCacheFreshnessQ 

Checks whether the cache has expired, if so refresh. 
Syntax: 

Private Sub CheckCacheFreshness () 
End Sub 

Example: 

CheckCacheFreshness 

FMControlO 

This API is used to fill Iistboxes or comboboxes with values from a list of CodeDecodes. 
Returns a collection for subsequent lookups to Code objects used to fill controls. 

Syntax: 

End Function 



Parameters: 

ctlControl: A reference to a passed in listbox or combobox. 

TZZZJZ^ZZT"- WhiCh Cl - fied "~ C ~ -erai 
craCatTaskType = l 
cmCat Source 
cmCatTaskStatus 

nFillType: The attribute of the CodeDecode which you want to fill c 

include: y ° U Want CO fil1 - Several of the valid values 
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cmCode 

cmShortDecode 
cnvLongDecode 

nCodeStatus: Optional value which filters the Code Decodes according to their Effective and 
Expiration dates. Several of the valid constants include ; 

cmAllCodes Pending -f Valid ♦ Expired Codes 

cmPendingCodes Codes whose effective date is greater than the current date 

cmValidCodes Not Pending or Expired Codes 

colAssignedCodes: Used when filling a control which should fill and include assigned values. 

Example: 

•Declare an instance variable for States collection on object 
Private colStates As CCollection 



'Call FillControll API , and set local collection inst var to collection of codes which were 
used to fill the controll. This collection will be used for subsequent lookups. 
Set colStates = ob j Arch .CodesMan. FillControl (frmCurrent Form. cboStates, cmCatStates, 
cmLong Decode ) 

FilterCodesQ 

Returns a collection of code/decodes that are filtered using their effective and expiration dates 
based on which nCodeStatus is passed from the fillcontrol method. 



Syntax: 

Private Function FilterCodes (colAHCodes As 

CCollection 

End Function 



CCollection, nCodeStatus As CodeDecode Filters) As 



Parameters: 

colAHCodes: 
nCodeStatus : 



Example: 

Set colFilteredCodes = FilterCodes (colCodes. nCodeStatus) 

GetCategoryCodesQ 

Returns a collection of CCode objects given a valid category 



Syntax: 



Public Function GetCategoryCodes (nCategory As CodeDecodeCats) As CCollection 
End Function 



Parameters: 

nCategory: The integer based constant which classified these CodeDecodes from others 

Example: 

Dim colMyStates As CCollection 

Set colMyStates = ob j Arch. CodesMan .GetCategoryCodes (cmCat States) 
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'Below shows an example of looking up the Code value for the currently selected state 
With frmCur rent Form. cboStates 
If .Li st Index > -1 Then 
Dim objCode As CCode 

Set objCode = colstates ( . ItemData ( -List Index) ) 
sStateCode = objCode. Code 
End If 
End With 

GetCodeObjectQ 

Returns a valid CCode object given a specific category and code. 



Syntax: 



Public Function GetCodeObject (nCategory As CodeDecodeCats, sCode As String) As CCode 
End Function 



Parameters: 

nCategory: The integer based constant which classified these CodeDecodes from others 
SCode: A string indicating the Code attribute of the CodeDecode object. 

Example: 

frmCurrentForm.lblState « objArch.CodesMan. GetCodeObject (cmCatStates, - 1 L" ). LongDecode 

GetResourceStringQ 

Returns a string from the resource file given a specific string ID. 



Syntax: 

Private Function Get ResourceSt ring (1st ringld As Long) As String 
End Function 

Parameters: 

lStringld: The id associated with the string in the resource file. 

Example: 

sMsg = arch.CodesMan.GetResourceString(CLng(vMessage) ) 

GetServerDateQ 

Returns the date from the server. 



Syntax: 



Private Function GetServerDate ( ) As Date 
End Function 
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Example: 

SetServerDate CCA.GetServerDate 

RefreshCacheQ 

Refreshes all of the code obhjects in the cache. 
Syntax: 

Private Sub Ref reshCache ( ) 
End Sub 

Example: 

m_Cache . Ref reshCache 

RemoveValidCodesQ 

Removes all valid codes from the passed in assigned codes collection, which is used to see which 
codes are assigned and not valid. 

Syntax: 

Private Sub Remove ValidCodes (sCode As String, col Pass edlnAssignedCodes As CCollection) 
End Sub 

Parameters: 

sCode: Name of code 

col Pass edlnAssignedCodes: Codes already in use. 

Example: 

ReraoveValidCodes codCode . Code . col Pass edlnAssignedCodes 

SetServerDate() 
Sets the server date. 

Syntax: 

Private Sub SetServerDate (dtServerDate As Date) 
End Sub 

Parameters: 

dtServerDate: Date of Server. 

Example: 

SetServerDate OCA.GetServerDate 

TextMan 
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The following are AP* located on the interface of the Arch Object 200 named TextMan 502 
PairUpAposts(); 
PairUpAmpsQ; and 
MergeParms (). 

PairUpAposts () 

Pairs up apostrophes in the passed string. 
Syntax: 

Public Function PairUpAposts (sOriginaiString As String) As String 
End Function 

Parameters: 

sOriginaiString: string passed in by the caller 

Example: 

Dim sString As String 

sString = ob j Arch. TextMan. PairUpAposts ( -This is Monika's string-) 
expected return: sString = -This is Monika"s string- 

PairUpAmps () 

Pairs up ampersands in the passed string. 
Syntax: 

Public Function PairUpAmps (sOriginaiString As String) As string 
End Function 

Parameters: 

SOriginaiString: string passed in by the caller 

Example: 

Dim sString As String 

sString = ob j Arch. TextMan. PairUpAmps ( "Forms &Corr- ) 
♦expected return: sString = «Forms*&Corr- 

MergeParms () 

Merges string with the passed parameters collection. 
Syntax: 

Z'tL^T* ——'-"^ *. colPacras As ccollection , As string 



60 



WO 00/67186 



PCT/US00/12508 



Parameters: 

sOriginalString : string passed in by the caller 

colParms As Ccollection: collection of the parameters passed in by the caller 

Example: 

Dim sString As String 

sString = obj Arch .TextMan .MergeParms (sString. colParms) 

IdMan 

The following are APIs located on the interface of the Arch Object 200 named IdMan 504: 

GetGUIDO; 

GetSequenceID(); 

GetTimeStampO; 

GetTrackingNbrO; and 

GetUniqueId(). 

GetGUIDO 

Syntax: 

Public Function GetGUIDO 
End Function 

Example: 

Dim vNewGuid As Variant 
vNewGuid = ob j Arch. IdMan .Get GUID 

GetSequenceld () 
Syntax: 

Public Function GetSequenceld {sTemplateType As Count erName) As String 
End Function 

Parameters: 

sTemplateType : The string specifying the template requesting a sequence id (i.e. cmCountFC 
Forms & Corr) 

Example: 

f rmCurren tForm.txt Tempi at eNumber = ob j Arch . IdMan. GetSequenceld (cmCountFC) 

GetTimeStamp () 
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Syntax; 

Public Function GetTimeStamp ( > 
End Function 

Example: 

Dim nNewTimeStamp As Long 

nNewTimeStamp , ob j Arch . IdMan. GetTimeStamp 



GetTrackingNbr 0 

Syntax: 

Public Function GetTrackingNbr ( ) 
End Function 

Example: 

Set objTechArch = New CTechArch 

sUniqueTrackNum , objTechArch . IdMan . GetTrackingNbr 

GetUniqueld () 

Syntax: 

Public Function GetUniqueld () 
End Function 

Example: 

Dim vUid As Variant 

vNewUid « ob j Arch. IdMan. GetUniqueld 



RegMan 

The following are APIs located on the interfaee of the Areh Objeet 200 named RegMan 506- 
GetCacheLifeQ; 

GetClientDSNO; 

GetComputerName(); 

GetDefaultAndVaIidate(); 

GetFCArchiveDirectoryO; 

GetFCDistributionDirectoryO; 

GetFCMasterDirectory(); 
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GetFCUserDirectoryO; 

GetFCWorkingDirectoryQ; 

GetHe!pPath(); 

GetLocallnfoO; 

GetLogLevel(); 

GetRegionalInfo(); 

GetRegValueO; 

GetServerDSNO; 

GetSettingO; 

GetTimerLogLevelQ; 

GetTimerLogPath(); and 

GetUseLocalCodesO- 

GetCacheLifeQ 
Syntax: 

Public Function GetCacheLife ( ) As String 
End Function 

Example: 

Dim 6 As String 

s = obj Arch. RegMan. GetCacheLife 

GetClientDSNQ 

Syntax: 

Public Function GetClientDSN( ) As String 
End Function 

Example: 

Dim s As String 

s = obj Arch. RegMan. GetClientDSN 

GetComputerNameQ 

Syntax: 

Public Function GetComputerName { ) As String 
End Function 

Example: 

Dim s As String 

s = obj Arch. RegMan. GetComputerName 
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GetDefaultAndValidateQ 

Syntax: 

™zzt°° GetDefau itAnavai idate<sK ey as s ^ *• ■«*- 

Parameters: 

»Ke y = The key within the registry of which the ^ requesting ^ ^ ; Heip pathj 

Example: 

Dim sDefault As String 

sDefault , objArch.RegMan.G^tDefaultAndValidateCsKey) 

Syntax 

Public Function GetFCArchiveDirectory {) As String 
End Function 

Example: 

Dim s As String 

s « ob jArch.RegMan. GetFCArchiveDirectory 

GetFCDistributionDirectoryQ 

Syntax: 

Public Function GetFCDistributionDirectory () As String 
End Function 

Example: 

Dim s As String 

s = objArch.RegMan.GetFCDistributionDirectory 

GetFCMasterDirectoryQ 

Syntax: 

Public Function GetFCMasterDirectory <) As String 
End Function 



Example: 

Dim s As String 

a = objArch.RegMan. GetFCMasterDirectory 

GetFCUserDirectoryQ 
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Syntax: 

Public Function Get FCUserDi rectory () As String 
End Function 

Example: 

Dim s As String 

s = ob j Arch. RegMan. Get FCUserDi rectory 

GetFCWorkingDirectoryO 

Syntax: 

Public Function GetFCWorkingDirectoryO As String 
End Function 

Example: 

Dim s As String 

s = obj Arch. RegMan. GetFCWorkingDi rectory 

GetHelpPathQ 

Syntax: 

Public Function GetHelpPathO As String 
End Function 

Example: 

Dim s As String 

s = ob j Arch. RegMan. GetHelpPath 



GetLocallnfoQ 

Syntax: 

Public Function Get Local Info ( ) As String 
End Function 

Example: 

Dim s As String 

s = objArch. RegMan. GetLocallnfo 

GetLogLevelQ 

Syntax: 

Public Function GetLogLevel ( ) As String 
End Function 

Example: 

Dim s As String 
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s = °b j Arch. RegMan. Get LogLevel 

GetRegionallnfoQ 

Allows access to all locale specific values which are set from control panel. 
Syntax: 

P^lic Function GetRegionallntoUnfo As Regionally. As String 
End Function 

Parameters: 

Info: string containing the regional information Several of ^ 

♦ cmLanguageid = «,! ' ^ ° f th * Valxd constants include: 

language id 

craLanguage Localized = &H2 , i^,, • 

# ^ localized name of language 

• cmLanguageEnglish = &H1001 . , - . m y 3 

• c-L^n^JL . ™ *" lxBh nAme of language 



• cmLanguageAbbr , , TZ " language 

• « . abbreviated language name 

• cmLanguageNative = &H4 . 

native name of language 



Example: 

Dim s As String 

s = obj Arch. RegMan. Get Regionallnfo 



GetRegValueQ 

Syntax: 

Public Function GetRegValue ( ) As String 
End Function 

Example: 

Dim s As String 

s * obj Arch. RegMan. GetRegValue 

GetServerDSNQ 
Syntax: 

Public Function GetServerDSN { ) As String 
End Function 

Example: 

Dim s As String 

■3 = obj Arch. RegMan. GetServerDSN 

GetSettingQ 

Get setting from the registry. 
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Syntax: 

Public Function Get Sett ing (s Key As String) As String 
End Function 

Parameters: 

sKey: The key within the registry ot which the user is requesting (i.e.: Help Path) 

Parameters: 

GetHelpPath = GetSetting (craRegHelpPathKey) 

GetTimerLogLevelQ 
Syntax: 

Public Function GetTimer Log Level ( ) As String 
End Function 

Example: 

Dim s As String 

s = obj Arch. RegMan. GetTimerLogLevel 

GetTimerLogPath() 

Syntax: 

Public Function GetTimerLogPath ( ) As String 
End Function 

Example: 

Dim s As String 

s = obj Arch. RegMan. GetTimerLogPath 

GetUseLocalCodesQ 

Syntax: 

Public Function GetUseLocalCodes ( ) As String 
End Function 

Example: 

Dim s As String 

s * obj Arch. RegMan. GetUseLocalCodes 

LPSTRToVBStringO 

Extracts a VB string from a buffer containing a null terminated string. 
Syntax: 

Private Function LPSTRToVBString$ (ByVal s$) 
End Function 
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LogMao 

The following are APIs located on the interface of the Arch Object 200 named LogMan 508: 
LogMessage (); 
WriteToDatabase(); and 
WriteToLocalLogQ. 



LogMessage () 

Used to log the message. This function will determine where the message 
should be logged, if at all, based on its severity and the vMsg's 
log level. 

Syntax: 

Public Sub LogMessage (vMsg As Variant, 

lSeverity As Long, 
sClassName As String, _ 
sMethodName As String, 
s Vers ion As String, 
lErrorNura As Long, 

Optional sText As String = vbNullString) 

End Sub 

Parameters: 

vMsg: the standard architecture message 

lSeverity z the severity of the message 

sClassName: the name of the class logging the message 

SMethodName: the name of the method logging the message 

sVersion: the version of the binary file (EXE or DLL) that contains the method logging 
message * 

lErrorNura: the number of the current error 

SText: an optional parameter containing the text of the message. If omitted, the text will 
be looked up in a string file or the generic VB error description will be used 

Example: 

It Err. Number <> o Then 
• log message 

Arch. LogMan. LogMessage {vMsg, cmSeverityFatal, •COrganizationCTLR" . "InitFomr. 

GetVersionO . Err. Number, Err .Description) 

1 re -raise the error 
Err. Raise Err .Number 
End If 



WriteToDatabase Q 

Used to log the message to the database on the server using the CLoggingComp. This function 
returns the Trackingld that is generated by the CLoggmgObject. 



68 



WO 00/67186 



PCT/US00/12508 



Syntax: 

Private Sub Wr iteToDat abase (vMsg As Variant, msgToLog As CMessage) 
End Sub 

Parameters: 

vMsg: the standard architecture message 

msgToLog: a parameter containing the text of the message. 

Example: 

It msgToLog - IsLoggableAtLevel (m_lLocalLogLevel ) Then 

Writ eToDat abase vMsg. msgToLog 
End If 

WriteToLocalLog () 

Used to log the message to either a flat file, in the case of Windows 95, or the NT Event Log, in 
the case of Windows NT. 

Syntax: 

Private Sub WriteToLocalLog (msgToLog As CMessage) 
End Sub 

Parameters: 

msgToLog: a parameter containing the text of the message. 

Example: 

ErrorHandler : 

WriteToLocalLog msgToLog 
End Sub 



ErrMan 

The following are APIs located on the interface of the Arch Object 200 named ErrMan 510: 

HandleErrorO; 

RaiseOriginalQ; 

ResetError(); and 

Update(). 

HandleError() 

This method is passed through to the general error handler in MArch.bas 
Syntax: 

Public Function HandleError { vMsg As Variant, nCompType As ContpType. sClassName As String, 
sMethodName As String) As ErrResume Codes 
End Sub 
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Parameters: 

vMsg: General Architecture information 

nCompType: Contains tier information (Client or Server) 
sClasaName: Class which raised the error 

sMethodName; Method which raised the error 



RaiseOriginalQ 

This method is used to Reset the error object and raise. 
Syntax: 

Public Sub RaiseOriginal ( ) 
End Sub 

Example: 

ob j Arch . Er rMan . Rai seOr ig ina 1 

ResetErrorQ 

This method is used to reset attributes. 
Syntax: 

Public Sub ResetErrorO 
End Sub 

Example: 

ob j Arch . ErrMan . Re se t Error 



UpdateO 

This method is used to update attributes to the values of VBs global Error object. 
Syntax: 

Public Sub UpdateO 
End Sub 

Example: 

ob j Arch . ErrMan . Update 



UserMan 

following are APIs located on the interface of the Arch Object 200 named UserMan 5 1 2. 
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Userld; 

Employeeld; 

EmployeeName; 

EmployeeFirstNarae; 

EmployeeLastName; 

EmployeeMiddlelnitial; 

GetAuthorizedEmployees; 

IsSuperOf(); 

IsRelativeOf(); and 

IsInRoleO- 

UserldQ 

Syntax: 

Public Property Get Userld () As String 
End Property 

Example: 

Dim sNewUserld As String 
sNewUserld = objArch. Us erMan. Userld 

EmployeeldQ 

Syntax: 

Public Property Get Employeeld () As String 
End Property 

Example: 

Dim sNevEmployeeld As String 
sNewBmployeeld = objArch.UserMan. Employeeld 



Employ eeNameQ 

Syntax: 

Public Property Get EmployeeName ( ) As String 
End Property 

Example: 



Dim sName As String 

sName = objArch.UserMan .EmployeeName 
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EmployeeFirstNameQ 

Syntax: 

Public Property Get EmployeeFirstName { ) As String 
End Property 

Example: 

Dim sFName As String 

sFName = objArch. UserMan. EmployeeFirstName 

Employ eeLastNameQ 

Syntax: 

Public Property Get EmployeeLastName < ) As String 
End Property 

Example: 

Dim sLName As String 

sLName = ob j Arch .UserMan. EmployeeLastName 

EmployeeMiddlelnitialO 

Syntax: 

Public Property Get EmployeeMiddlelnitialO As String 
End Property 

Example: 

Dim sMI As String 

SMI s ob j Arch. UserMan -EmployeeMiddle Initial 

GetAuthorizedEmployeesQ 

Creates a collection of user's supervisees from the dictionary and returns 
GetAuthorizedEmployees - collection of authorized employees 

Syntax: 

Public Function GetAuthorizedEmployees {) As CCollection 
End Function 

Example: 

Dim colAuth As Collection 

colAuth = obj Arch -UserMan. GetAuthorizedEmployees 

IsSuperOfO 

Checks if the current user is supervisor of the passed in user. 
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Syntax: 

Public Function IsSuperOf ( sEmpId As String) As Boolean 
End Function 

Parameters: 

sEmpId: string containing Employee ID number 

Example: 

Dim blsSuperOfMonika As Boolean 

blsSuperOfMonika = objArch.UserMan. IsSuperOf ( *TS01234 5* ) 

IsRelativeOfQ 

Checks if the passed in user is relative of the current user. 
Syntax: 

Public Function IsRelativeOf (sEmpId As String) As Boolean 
End Function 

Parameters: 

sEmpId: string containing Employee ID number 

Example: 

Dim blsRelativeOfMonika As Boolean 

blsRelativeOfMonika = ob j Arch .UserMan . IsRelativeOf ( "TS01234S - ) 



IsInRole Q 

Checks to see if the current user is in a certain role. 
Syntax: 

Public Function IsInRole (sRole As String) As Boolean 
End Function 

Parameters: 

sRole: string containing role 

Example: 

Dim blsInRoleTaskLibrarian As Boolean 

blsInRoleTaskLibrarian = obj Arch. UserMan . IsInRole { *TA- ) 
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SecuntyMan 

The following APIs are located on the interface of the Arch Object 200 named SecurityMan 5 14. 

EvalCiaimRules; 

EvalFileNoteRuIes; 

EvalFormsCorrRules; 

EvalOrgRules; 

EvalRunApplicationRules; 

EvalRunEventProcRules; 

EvalTaskTemplateRules; 

EvalUserProfilesRules; 

IsOperAuthorized; 

GetUserld; and 

OverrideUser, 

EvalCiaimRules Q 

TWs API references business rules for Claim security checking and returns a boolean if rules are 
Syntax: 

Private function Evaldai-Rules UBasicOp As onBasicOperations. vContextData As Variant, 
End Function 

Parameters: 

v^SoaJ ba3lC OPerati ° a CUrrCnt " Ser " Wishi " 9 t0 P « £o ™ O-l-f > 

VContextData: a variant array holding relevant business objects or other inform 



ion. 



Example: 

Select Case lOperation 
Case cmWorkOnClaitn 

IsOperAuthorized = EvalCiaimRules (cmView, vContextData) And _ 
EvalCiaimRules <cm£dit, vContextData) 

EvalFileNoteRuIes () 

TOsAPI references business rules for FileNote security checking and returns a boolean if rules 
Syntax: 

Private Action EvaimeKoteK.les UBasicOp As cooperations . vContextData As Variant, fls 



Boolean 
End Function 
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Parameters: 

IBasicOp: a basic operation Che current user is wishing to perform (i.e. Delete) 
vContextData : a variant array holding relevant business objects or other information. 

Example: 

Select Ca9e loperation 
Case craDeleteFileNote 

IsOperAuthorized = EvalFileNoteRules (craDelete. vContextData) 



EvalFormsCorrRules () 

This API references business rules for Forms and Corr security checking and returns a boolean if 
rules are met. 

Syntax: 

Private Function EvalFormsCorrRules (IBasicOp As cmBasicOpe rat ions) As Boolean 
End Function 

Parameters: 

IBasicOp: a basic operation the current user is wishing to perform (i.e. Delete) 

Example: 

Select Case lOperation 
Case cmMaintainFormsCorr 

IsOperAuthorized = EvalFormsCorrRules (cmEdit) And _ 

EvalFormsCorrRules (cmDelete) And _ 

EvalFormsCorrRules (cmAdd) 

EvalOrgRules 0 

This API references business rules for Event Processor security checking and returns a boolean if 
rules are met. 

Syntax: 

Private Function EvalOrgRules (IBasicOp As cmBasicOperations) As Boolean 
End Function 

Parameters: 

IBasicOp: a basic operation the current user is wishing to perform (i.e. Delete) 

Example: 

Select Case lOperation 
Case cmMaintainOrg 

IsOperAuthorized = EvalOrgRules (cmAdd) And _ 
EvalOrgRules (cmEdit) And _ 

75 



WO 00/67186 



PCT/US00/12508 



EvalOrgRules (cmDelete, 



EvalRunApplicationRules () 

This API references business rules for running the application and returns a boolean if rules are 
Syntax: 

Private Function EvalRunApplicationRules (iBasicOp As cmBasicOpe rat ions, As Boolean 
End Function 

Parameters: 

IBasicOp: a basic operation the current user is wishing to perform (i.e. Delete, 

Example: 

Select Case lOperation 

Case ctnRunApplication 

IsOperAuthorized = EvalRunApplicationRules (craExecute) 

EvalRunEventProcRules Q 

^es^cmIt CnCGS bUSineSS m,CS EVCnt Pr ° CeSSOr SeCUdty ChCcking md retums a boolean if 
Syntax: 

Private Function EvalRunEventProcRules (IBasicOp As onBas ^Operations) As Boolean 
End Function 

Parameters: 

IBasicOp: a basic operation the current user is wishing to perform (i.e. Delete, 

Example: 

Select Case lOperation 
Case cmRunEventProcessor 

IsOperAuthorized = EvalRunEventProcRules (cmExecute, 



EvalTaskTemplateRules () 

^s^emt^ bUSineSS mleS ^ ^ Template SeCUnty Checkin § md retums a boole *n if 
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Syntax: 

Private Function EvalTaskTemplateRules ( IBasicOp As cmBasicOpe rat ions) As Boolean 
End Function 

Parameters: 

IBasicOp: a basic operation the current user is wishing to perform (i.e. Delete) 

Example: 

Select Case lOperation 
Case cmMaintainTaskLibrary 

IsOperAuthorized = EvalTaskTemplateRules (cmAdd) And _ 

EvalTaskTemplateRules (craBdit) And 

EvalTaskTemplateRules (cmDelete) 

EvaWserProfileRules () 

This API references business rules for Task Template security checking and returns a boolean if 
rules are met. 

Syntax: 

Private Function Eva 1 User Pro fileRules (IBasicOp As cmBasicOpe rat ions, vContextData As Variant) 
As Boolean 
End Function 

Parameters: 

IBasicOp: a basic operation the current user is wishing to perform (i.e. Delete) 
vContextData: a variant array holding relevant business objects or other information. 

Example: 

Select Case lOperation 

Case cmlsRelativeOf 

IsOperAuthorized f EvalUserProf ileRules (cmView, vContextData) And _ 
EvalUserProf ileRules (cmAdd, vContextData) And _ 
EvalUserProf ileRules (cmEdit, vContextData) And _ 
EvalUserProf ileRules (cmDelete, vContextData) 

GetUserldQ 

Returns the login name/user id of the current user. 
Syntax: 

Public Function GetUserldO As String 
End Function 

Example: 

Dim sUserld as String 
sUserld = GetUserld 
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IsOperAuthorized () 

This API references business rules and returns a boolean determining whether the user has 
security privileges to perform a certain operation. 

Syntax: 

Public Function IsOperAuthorized (vMsg. as variant. nOperation as ^Operations, vContext As 
Variant) As Boolean 
End Function 

Parameters: 

vMsg: the standard architecture message 

nOperation: an enumeration containing name of operation to be checked 

vContext: a variant array holding relevant business objects or other information. 

Example: 

Dim bCanlDoThis As Boolean 

bCanlDoThis = obj Arch. SecurityMan. IsOperAuthorized (vMsg, aOperat ionName , vContext) 
TlbEdit I con. Enabled = bCanlDoThis 



OverrideUser 0 

Re-initializes for a different user. 
Syntax: 

Public Sub OverrideUser(Optional sUserld As String, Optional dictRoles As CDi, 
Optional dictSubs As CDictionary) 
End Function 



Parameters: 

sUserld: 
dictRoles : 
dictSubs : 



Example: 

Dim x As New CTechArch 

x. SecurityMan. OverrideUser -Everyone", New CDictionary, New CDictionary 



CODES FRAMEWORK 
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General Requirements 

Separate tables (CodesDecodes) are Created for storing the static values. 

Only the references to codes/decodes are stored in business tables (e.g., Task) which utilize these 
values. This minimizes the size of the business tables, since storing a Code value takes much less 
storage space than its corresponding Decode value (e.g., For State, "AL" is stored in each table 
row instead of the string "Alabama"). 

CodeDecodes are stored locally on the client workstation in a local DBMS. On Application 
startup, a procedure to ensure the local tables are in sync with the central DBMS is performed. 



Infrastructure Approach 

The present invention's Code Decode Infrastructure 600 Approach outlines the method of 
physically modeling codes tables. The model allows codes to be extended with no impact to the 
physical data model and/or application and architecture. Figure 6 shows the physical layout of 
CodeDecode tables according to one embodiment of the present invention. 

Infrastructure 

The physical model of the CodeDecode infrastructure 600 does the following: 

Supports relational functionality between CodeDecode objects; 

Supports extensibility without modification to the DBMS or Application Architecture; 

Provides a consistent approach for accessing all CodeDecode elements; and 
Is easily maintainable. 

These generic tables are able to handle new categories, and modification of relationships without 
a need to change the DBMS or CodeDecode Application Architecture. 
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Benefits of this model are extensibility and maintainability. This model allows for the 
modifications of code categories without any impact to the DBMS or the Application 
Architecture code. This model also requires fewer tables to maintain. In addition, only one 
method is necessary to access CodeDecodes. 



Table Relationships and Field Descriptions: 

(pic) indicates a Primary Key 

Code_Category 602 

• C Category (pk): The category number for a group of codes 

• C_Cache (currently not utilized): Can indicate whether the category should be cached in 
memory on the client machine 

• T_Category: A text description of the category (e.g., Application Task Types, Claim 

Status, Days of Week) 

• DJLast Update: The date any data within the given category was last updated; this field 

is used in determining whether to update a category or categories on the local data base 
Relationships 

• A one-to-many relationship with the table Code (i.e., one category can have multiple 
codes) 



Code 604 

• C Category (pk): The category number for a group of codes 

• C_Code (pk): A brief code identifier (up to ten characters; the current maximum length 
being used is five characters) 

• D Effective: A date field indicating the code's effective date 

• DExpiration: A date field indicating the code's expiration date (the default is January 1, 
2999) 

Relationships 

• A many-to-one relationship with Code_Category 602 (described above) 

• A one-to-many relationship with CodeJRelations 606 (a given category-and-code 
combination can be related to multiple other category-and-code combinations) 
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Code_Relations 606 

• CCategoryl (pk): The first category 

• C_Codel (pk): The first code 

• C_Category2 (pk): The related category 

• C_Code2 (pk): The related code 
Relationships 

• A many-to-one relationship with the Code table (each category and code in the Code 
table can have multiple related category-code combinations) 

Code ^Decode 608 

• C_Category (pk): The category number for a group of codes 

• C_Code (pk): A brief code identifier (up to ten characters; the current maximum length 
being used is five characters) 

• N Lang ID (pk): A value indicating the local language setting (as defined in a given 

machine's Regional Settings). For example, the value for English (United States) is 
stored as 0409. Use of this setting allows for the storage and selection of text code 
descriptions based on the language chosen 

• T_Short_Desc: An abbreviated textual description of C_Code 

• T_Long_Desc: A full-length textual description of C_Code — what the user will actually 

see (e.g., Close Supplement - Recovery, File Note, Workers Compensation) 

Localization Support Approach 

Enabling Localization 

Codes have support for multiple languages. The key to this feature is storing a language 
identifier along with each CodeDecode value. This Language field makes up a part of the 
compound key of the CodeDecode table. Each Code API lookup includes a system level call to 
retrieve the Language system variable. This value is used as part of the call to retrieve the values 
given the correct language. 
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Maintaining Language Localization Setting 

A link to the Language system environment variable to the language keys is stored on each 
CodeDecode. This value is modified at any time by the user simply by editing the regional 
settings User Interface available in the Microsoft Windows Control Panel folder. 



Codes Expiration Approach 

Handling Time Sensitive Codes becomes an issue when filling controls with a list of values. 
One objective is to only allow the user to view and select appropriate entries. The challenge lies 
in being able to expire Codes without adversely affecting the application. To achieve this, 
consideration is given to how each UI will decide which values are appropriate to show to the 
user given its current mode. 

The three most common UI modes that affect time sensitive codes are Add Mode, 
View Mode, and Edit Mode. 

Add Mode 

In Add Mode, typically only valid codes are displayed to the user as selection options. Note that 
the constant, cmValidCodes, is the default and will still work the same even when this optional 
parameter is omitted. 

Set colStates = objArch.CodesMan.F^^ cmCatStates, 
cmLongDecode, cmValidCodes) 

View Mode 

In View Mode, the user is typically viewing results of historical data without direct ability to 
edit. Editing selected historical data launches another UI. Given this the controls are filled with 
valid and expired codes, or in other words, non-pending codes. 

Set colStates = objArch.CodesMan.FillControKfiTnCurrentFonn.cboStates, cmCatStates, 
cmLongDecode, cmNonPendingCodes) 
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Edit Mode 

In Edit Mode, changes are allowed to valid codes but also expired codes are displayed if already 
assigned to the entity. 

Dim colAssignedCodes As New cCollection 
colAssignedCodes.Add HistoricalAddress.State 

Set colStates = objArch.CodesMan.FillControl(fhnCurrentForni.cboStates, cmCatStates, 
cmLongDecode, cmValidCodes, colAssignedCodes) 

Updating Local CodeDecodes 

The Local CodeDecode tables are kept in sync with central storage of CodeDecodes. The 
architecture is responsible for making a check to see if there are any new or updated code 
decodes from the server on a regular basis. The architecture also, upon detection of new or 
modified CodeDecode categories, returns the associated data, and performs an update to the local 
database. Figure 7 is a logic diagram for this process 700. 

After an API call, a check is made to determine if the Arch is initialized 702. If it is a check is 
made to determine if the Freshness Interval has expired 704. If the Freshness Interval has not 
expired, the API call is complete 706. However, if either the Arch is not initialized or the 
Freshness Interval has expired, then the "LastUpdate" fields for each category are read from the 
CodeDecode and passed to the server 708. Then new and updated catagories are read from the 
database 710. Finally the Local database is updated 712. 

Code Access APIs 

The following are APIs located on the interface of the Arch Object 200 named CodesMan 500. 

GetCodeObject(nCategory, sCode); 

GetCategoryCodes(nCategory); 

FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], [colAssignedCodes]). 

GetCodeObject: Returns a valid CCode object given a specific category and code. 
Syntax: 

GetCodeObject( nCategory. sCode) 
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Parameters: 

nCategory: The integer based constant which classified these CodeDecodes from others. 
sCode: A string indicating the Code attribute of the CodeDecode object. 

Example: 

t recurrent Form, lbl State = objArch.CodesMan.GetCodeObject (cmCatStates, * IL" ) . Long Decode 

GetCategoryCodes: Returns a collection of CCode objects given a valid category 
Syntax: 

GetCategoryCodes(nCategory) 
Parameters: 

nCategory: The integer based constant which classified these CodeDecodes from others. 
Example: 

Dim colMystates As CCollection 

Set colMystates = objArch.CodesMan.GetCategory (cmCatStates) 

FillControl: This API is used to fill listboxes or comboboxes with values from a list of 
CodeDecodes. Returns a collection for subsequent lookups to Code objects used to fill controls. 

Syntax: 

FiIlControl(ctlControl, nCategory, nFiUType, [nCodeStatus], [colAssignedCodesJ) 
Parameters: 

ctlControl: A reference to a passed in listbox or combobox. 

nCategory: The integer based constant which classified these CodeDecodes from others. 
nFillType: The attribute of the CodeDecode which you want to fill. Valid values include: 

cmCode 

cmShortDecode 
cmLongDecode 

nCodeStatus: Optional value which filters the Code Decodes according to their Effective 
and Expiration dates. Valid constants include the following: 

cmAHCodes Pending ♦ Valid + Expired Codes 

craPendingCodes Codes whose effective date is greater than the current date 

cmValidCodes Not Pending or Expired Codes 

craExpiredCodes Codes whose expired date is greater than the current date 

cinNonPendingCodes Valid + Expired Codes 

cmNonValidCodes Pending + Expired Codes 

cmNonExpiredCodes Pending + Valid Codes 

colAssignedCodes: Used when filling a control which should fill and include assigned 
values. 

Example: 
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'Declare an instance variable for States collection on object 

Private colStates As CCollection 

'Call FillControl API, and set local collection inst var to collection of codes which were 
5 used to fill the control. This collection will be used for subsequent lookups. 

Set colStates = ob j Arch .CodesMan. FillControl (frmCur rent Form. cboStates, cmCatStates, 
craLongDecode > 

4 Below shows an example of looking up the Code value for the currently selected state. 
10 With frmCur rent Form. cboStates 

If .List Index > -I Then 
Dim objCode As CCode 

Set objCode = colStates < .ItemData( .List Index) ) 
sStateCode - objCode. Code 
15 End If 

End With 



20 Relational Codes Access APIs 

Code objects returned via the "GetCodeObject" or "GetCategoryCodes" APIs can have relations 
to other code objects. This allows for functionality in which codes are associated to other 
individual code objects. 

25 

The APIs used to retrieve these values are similar to those on the CodesMan interface. The 
difference, however is that the methods are called on the Codes object rather that the 
CodesManager interface: Listed below again are the APIs. 

30 GetCodeObject(nCategory, sCode); 
GetCategoryCodes(nCategory); 

FillControl(ctlControl, nCategory, nFillType, [nCodeStatus], [colAssignedCodes]). 

Given below is some sample code to illustrate how these APIs are also called on Code objects. 

35 

GetCodeObject Example: 

Dim objBondCode As CCode 

Set objBondCode = objArch . Codes Man. GetCodeObject (cmCatLOB . -B') 
40 Dim objSuretyCode As CCode 

Set objSuretyCode - objBondCode .GetCodeObject (craCat Supplement , "B01") 

GetCategory Example: 

45 Dim objBondCode As CCode 

Set objBondCode = objArch. CodesMan .GetCodeObject (cmCatLOB, *B") 
Dim col Supplements As CCol lection 

Set colSupplements = ob jBondCode. Get Cat ego ry{cmCat Supplement ) 
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FUIControl Example: 

Dim objBondCode As CCode 

Set objBondCode = ob j Arch. CodesMan. GetCodeOb j ect {cmCat LOB, *B" ) 
Dim col Supplements As CCol lection 

Set colSupplements = objBondCode . FillControl (frmForm. cboSupplements, cmCat Supplements, 
cmLongDecode } 



MESSAGE LOGGING 

The message logging architecture allows message logging in a safe and consistent manner. The 
interface to the message logging component is simple and consistent, allowing message logging 
on any processing tier. Both error and informational messages are logged to a centralized 
repository. 

Abstracting the message logging approach allows the implementation to change without 
breaking existing code. 

Best Practices 

Messages are always logged by the architecture when an unrecoverable error occurs (i.e., the 
network goes down) and it is not explicitly handled. Message logging may be used on an as- 
needed basis to facilitate the diagnosis and fixing of SERs. This sort of logging is especially 
useful at points of integration between classes and components. Messages logged for the 
purpose of debugging have a severity of Informational, so as not to be confused with legitimate 
error messages. 



Usage 

A message is logged by calling the LogMessage() function on the architecture. 

Description of Parameters: 
vMsg: the standard architecture message 
lSeverity: the severity of the message 
sClassName: the name of the class logging the message 
sMethodName: the name of the method logging the message 
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sVersion: the version of the binary file (EXE or DLL) that contains the method logging the 
message 

lErrorNum: the number of the current error 

sText: an optional parameter containing the text of the message. If omitted, the text will be 
looked up in a string file or the generic VB error description will be used. 
sText: an optional parameter containing the text of the message. If omitted, the text will be 
looked up in a string file or the generic VB error description will be used. 
lLoggingOptions : an optional parameter containing a constant specifying where to log the 
message (i.e., passing cmLogToDBAndEventViewer to LogMessage will log the error to the 
database and the event viewer.) 

Logging Levels 

Before a message is logged, its severity is compared to the log level of the current machine. If 
the severity of the message is less than or equal to the log level, then the message is logged. 



Valid values for the log level are defined as an enumeration in VB. They include: 



Value 


Name 


Description 


Example 


0 


CmFatal 


A critical condition that closes or 
threatens the entire system 


Application Server 
crash 


1 


CmSevere 


A condition that closes or threatens a 
major component of the entire system 


Network failure 


2 


CmWarning 


A warning that something in the system 
is wrong but it does not close or 
threaten to close the system 


Optimistic locking 
error 


3 


Cmlnformation 
al 


Notification of a particular occurrence 
for logging and audit purposes 


Developer debugging 
information 



Example 

If Err. Number <> 0 Then 
' log message 

Arch -LogMan. LogMessage (vMsg, croSe verity Fatal , ""COrganizationCTLR- , •InitForra", 
GetVersionO , Err. Number, Err .Descript ion) 

* re- raise the error 
Err. Raise Err. Number 
End If 



Database Log 

The database log table is composed of the following fields: 
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Field Name 
N MSG ID 



D MSG 



C ERR SEV 



N USER ID 



NMACH ID 



M CLASS 



M METHOD 



NCMPNT VER 



C ERR 



T MSG 



Description 

Unique ID of the message 



Date the message occurred 



Severity of the error 



Name of user when error occurred 



Name of the machine that the error occurred on 



Name of the class that the error occurred in 



Name of the method that the error occurred in 



Version of the binary file that the error occurred in 



Number of the error 



Text of the message 



Local Log 

Messages are always logged to the application server's Event Log; however this is not 
necessarily true for the database as noted by the optional parameter passed to LogMessage, 
ILoggingOptions. An administrator with the appropriate access rights can connect to the MTS 
application server remotely and view its Event Log. Only one MTS package contains the Event 
Log Component, so that errors will all be written to the same application server Event Log. 

Events logged via Visual Basic always have "VBRuntime" as the source. The Computer field is 
automatically populated with the name of the computer that is logging the event (i.e., the MTS 
application server) rather than the computer that generated the event (typically a client 
computer). 

The same event details that are written to the database are formatted into a readable string and 
written to the log. The text "The VB Application identified by ... Logged:" is automatically 
added by VB; the text that follows contains the details of the message. 



DATA ACCESS 

All but a few exceptional cases use the "ExecuteQuery" API. This API covers singular database 
operations in which there exists a single input and a single output. Essentially should only 
exclude certain batch type operations. 
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The Data Access Framework serves the purposes of performance, consistency, and 
maintainability. 



Performance 

The "ExecuteQuery" method incorporates usage patterns for using ADO in an efficient manner. 
Examples of these patterns include utilization of disconnected recordsets, and explicitly 
declaring optional parameters which result in the best performance. 

Consistency 

This method provides a common interface for development of data access. Given a simple and 
stable data access interface, best practices can be developed and disseminated. 

Maintainability 

Since the method is located in a single location, it is very modularized and can be maintained 
with little impact to its callers- 
Application servers often use the ActiveX Data Objects (ADO) data access interface. This 
allows for a simplified programming model as well as enabling the embodiments to utilize a 
variety of data sources. 

The "ExecuteQuery" Method 

Overview 

The "ExecuteQuery" method should be used for most application SQL calls. This method 
encapsulates functionality for using ADO in a effective and efficient manner. This API applies 
to situations in which a single operation needs to be executed which returns a single recordset 
object. 

Syntax 

Set obj = ExecuteQuery (vMsg, nTranType, sSQL. [nMaxRowsl , [adoTransConn] , largsl ) 

Parameters 

vMsg 
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This parameter is the TechArch struct. This is used as a token for information 
capture such as performance metrics, error information, and security. 

nTranType 

An application defined constant which indicates which type of operation is being 
performed. Values for this parameter can be one of the following constants: 

cmSelect 

cmSelectLocal 

cmUpdate 

cmlnsert 

cmDelete 

sSQL 

String containing the SQL code to be performed against the DBMS. 

nMaxRows (Optional) 

Integer value which represent the maximum number of records that the recordset of the 
current query will return. 

adoTransConn (Optional) 

An ADO Connection object This is created and passed into execute query for operations 
which require ADO transactional control (see "Using Transactions" section) 

args (Optional) 

A list of parameters to be respectfully inserted into the SQL statement. 
Implementation 

In one embodiment of the present invention the "ExecuteQuery" method resides within the 
MservArch.bas file. This file should be incorporated into all ServeiComponent type projects. 
This will allow each server component access to this method. 

Note: Since this method is a public method in a "bas" module, it is globally available from 
anywhere in the project. 

Public Function ExecuteQuery (vMsg As Variant. 

nTranType As TranTypes, 
sSQL As String. 

Optional nMaxRows As Integer = 0. 
Optional adoTransConn As ADODB . Connection. 
Optional colArguments As CCollection) As Variant 
On Error GoTo ErrorHandler 
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Const cmMethodName As String = "ExecuteOuery- 

StartTiraeLogger vMsg. cmTimerldDBTotal , cmClassName, cmMethodName 

•find out if this call is an isolate operation or 
'part of an ADO (not MTS) transaction 
Dim isAtoraicTrans As Boolean 
isAtomicTrans = adoTransConn Is Nothing 

Dim nRecordsAf fected As Integer 
Dim adoRS As New ADODB . Recordset 
Dim adoConn As ADODB . Connection 
Dim lAuxEr rNumbe r As Long 

•open a new connection or keep using the passed in connection 

Set adoConn = I If (isAtomicTrans. New ADODB. Connect ion, adoTransConn) 

If isAtomicTrans Then 

adoConn. Open cmODBC_Connect 

•ADO will wait indefinitely until the execution is complete during performance 
testing 

SIf IsPerfTest Then 

adoConn. CommandTinie out = 0 
8 End If 
End If 

'Make sure date args are formatted for DB2 if appropriate 
If Not colArguments Is Nothing Then _ 

Set colArguments = FormatArgs For DB 2 (colArguments) 

'merge the passed in arguments with the SQL string 
sSQL = MergeSQL(sSQL, colArguments) 

Debug. Print Time & n : w & sSQL 

'execute the SQL statement depending on the transaction type 
Select Case CStr (nTranType) 
Case cmSelect 

adoRS - MaxRecords = nMaxRows 

adoRS. Cursor Location = adUseClient 

adoRS.Open sSQL, adoConn, adOpenForwardOnly, adLockReadOnly, adCmdText 
Set adoRS.ActiveConnection = Nothing 
Set ExecuteQuery = adoRS 
Case cmSelectLocal 

adoRS . MaxRecords = nMaxRows 
adoRS.CursorLocation = adUseClient 

adoRS.Open sSQL, adoConn. adOpenStatic. adLockBatchOptimistic, adCmdText 
Set adoRS.ActiveConnection - Nothing 
Set ExecuteQuery = adoRS 
Case cmlnsert 

Set adoRS = adoConn. Execute (sSQL, nRecordsAf fected, adCmdText) 
If nRecordsAf fected <= 0 Then Err. Raise cmErrQuery Insert 
Set adoRS = Nothing 
ExecuteQuery = nRecordsAf fected 
Case cmUpdate. cmDelete 

Set adoRS = adoConn. Execut e (sSQL, nRecordsAf fected, adCmdText) 
If nRecordsAf fected <- 0 Then Err. Raise craErrOptimisticLock 



91 



WO 00/67186 



PCT/USOO/12508 



Set adoRS m Nothing 
ExecuteQuery = nRecordsAf f ected 
Case cmSpFileNote 

Set adoRS = adoConn. Execute (sSQL, nRecordsAf f ected. adCmdText) 
Set adoRS = Nothing 
Case Else 

Err. Raise cmErrlnvalidParameters 
End Select 

StopTimeLogger vMsg, cmTimerldDBTotal , cmClassName, cmMethodName 
Exit Function 

ErrorHandler : 

Dim objArch As Object 

Set objArch = CreateObject { "craArch.CTechArch 0 ) 

Select Case CStr(Err) 

Case cinErrQuerylnsert. cmErrOptimisticLock, cmErrlnvalidParameters 
'Raise error 
Err. Raise Err 

Case cmErrDSNNot Found 

Dim sMsgText As String 

sMsgText » "Data Source Name not found." & vbCrLf & ■ ( « £ 
CStr (objArch. RegMan.GetServerDSN) & - )« 

Create a new message log and log the message 
objArch.LogMan.LogMessage vMsg, cmSeverityFatal , cmClassName. cmMethodName, 

Get version (), cmErrDSNNot Found, sMsgText, cmLogToEventViewerOnly 

lAuxErrNumber = adoConn . Errors ( 0 >. Nat iveError 'The error code is stored since 

when closing the conection it will 
be lo3t 

If adoConn. State <> adStateClosed Then adoConn. Close 

Err. Raise cmErrDSNNot Found, , sMsgText 
Case Else 

Create a new message log and log the message 
objArch. LogMan.LogMessage vMsg, cmSeverityFatal, cmClassName. cmMethodName, 

GetVersionO, Err. Number, Err .Description, cmLogToEventViewerOnly 

lAuxErrNumber = adoConn. Errors (0) .Nat iveError 'The error code is stored since 

when closing the conection it will 
be lost 

If adoConn. State <> adStateClosed Then adoConn. Close 
Err. Raise lAuxErrNumber 
End Select 
End Function 



Selecting Records 

ExecuteQuery utilizes disconnected recordsets for "Select" type statements. This requires that 
the clients, particularly the CCA's contain a reference to ADOR, ActiveX Data Object 
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Recordset. This DLL is a subset of the ADODB DLL. ADOR contains only the recordset 
object. 



Using disconnected recordsets allows marshalling of recordset objects from sever to client. This 
performs much more efficiently than the variant array which is associated with using the 
"GetRows" API on the server. This performance gain is especially apparent when the 
application server is under load of a large number of concurrent users. 

Sample from Client Component Adapter (CCA) 

Dim vAns as Variant 

Dim adoRS As ADOR . Recordset 

Set adoRS = obj Server . Perf ormSelect (vMsg r nld) 
If obj RS . EOF Then 

Set objRS = Nothing 

Exit Function 
End If 

vAns = adoRS .Get Rows 
Set adoRS = Nothing 

'Marshall vAns into objects 



Sample from Server Component 

Private Const cmCustSQL = "Select * from Customer where id » ?" 

Public Function Perf ormSelect (vMsg, nld) a3 Variant 
Dim colArgs as CCol lection 
Set colArgs = New Ccol lection 
colArgs. Add nld 

Set Perf ormSelect = ExecuteQuery (vMsg, cmSelect, sCustSQL, , , colArgs) 
End Function 

Code Clip from ExecuteQuery (Select Section) 

Case cmSelect 

adoRS . MaxRecords = nMaxRows 

adoRS .Cursor Location = adUseClient 

adoRS.Open sSQL, adoConn, adOpenForwardOnly , adLockReadOnly. adCmdText 
Set ExecuteQuery * adoRS 



Inserting Records 



93 



WO 00/67186 

PCT/USOO/12508 



server a 



Inserting records requires certain information pertaining to optimistic locking. On the : 
unique value is requested to indicate the last time modified. This unique value is returned back 
to the requestor such that it can be used to later database operations. 

Sample from Client Component Adapter (CCA) 

Dim vNewTS as Variant 

vNewTS = objServer.PerformInsert<vMsg, rud, sName) 
'Set object's TimeStamp to vNewTS 

Sample from Server Component 

Private Const cmCustlnsertSQL , -Insert Customer <nld. N ame, LastUpdated, Values< ? , ?) . 

Public Function Performlnsert <v Msg . nld. sName) As Variant 

Dim ICurrTS as Long 

lCurrTS = GetTimeStamp 

Dim colArgs as CCol lection 

Set colArgs = New Ccollection 

colArgs. Add nld 

colArgs. Add sName 

colArgs. Add lCurrTS 

ExecuteQuery(vMsg. cmlnsert. sCustlnsertSQL, t , colArgs) 
Performlnsert = lCurrTS 

Code Clip from ExecuteQuery (Insert Section) 

Case cmlnsert 

Set adoRS » adoConn . Execute f sSQL , nRecords Affected. adCmdText) 
If nRecordsAffected < = 0 Then Err. Raise cmErrQuerylnsert 
Set adoRS = Nothing 
ExecuteQuery = nRecordsAffected 



Updating Records 

Updating records requires certain information pertaining to optimistic locking. On the server a 
unique value is requested to indicate the last time modified. Also the last read timestamp is used 
to validate, during the update, that the record has not been modified since last time read. 

Sample from Client Component Adapter (CCA) 

Dim vNewTS as Variant 

VNewTS = ob j Server. Perf ormUpdate (vMsg. 1, 'Rick' , 89076S4) 
'Set object's TimeStamp to vNewTS 

Sample Code Clip from Server Component 

Private Const cmCustUpdateSQL = 

"Update Customer Set Name - '?'. LastUpdated = ? - & 
"Where Id = ? • & 
"And La st Updated = ? - 
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Public Function Perf ormUpdate (vMsg. nld, sName, lLastTS) As Variant 
Dim lCurrTS as Long 
lCurrTS = GetTiraeStamp 
Dim colArgs as CCollection 
Set colArgs = Mew Ccol lection 
colArgs. Add sName 
colArgs. Add lCurrTS 
colArgs. Add nld 
colArgs -Add lLastTS 

Perf ormUpdate ■ ExecuteQuery (vMsg, cmUpdate, sCust Update SQL, . . colArgs) 
Perf ormUpdate = lCurrTS 
End Function 

Code Clip from ExecuteQuery (Update Section) 

Case cmUpdate 

Set adoRS « adoConn. Execute (sSQL, nRecordsAf fected, adCmdText) 
If nRecordsAf fected < 0 Then Err. Raise cmErrOptimisticLock 
ExecuteQuery = nRecordsAf fected 



Deleting Records 

In deleting records the last read timestamp is used to validate, during the delete, that the record 
has not been modified since last time read. 

Sample from Client Component Adapter (CCA) 

Dim vAns as Variant 

vAns = objServer. Per forraDelete (vMsg, nld , lLastTS) 

Sample from Server Component 

Private Const cmCustDeleteSQL = _ 
* Delete From Customer * & _ 
"Where Id = ? • & _ 
•And Last updated « ? - 

Public Function Perf orraDelete (vMsg, nld lLastTS) As Variant 
Dim colArgs as CCollection 
Set colArgs = New Ccol lection 
colArgs .Add nld 
colArgs. Add lLastTS 

PerformDelete - ExecuteQuery <vMsg, cmDelete, cmCustDeleteSQL) 
Exit Punction 

Code Clip from ExecuteQuery (Delete Section) 

Case cmDelete 

Set adoRS = adoConn . Execute (sSQL, nRecordsAf fected, adCmdText) 
If nRecordsAf fected < 0 Then Err. Raise cmErrOptimisticLock 
ExecuteQuery = nRecordsAf fected 
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DATABASE LOCKTNC FRAMEWORK 



Database Locking ensures the integrity of the database in a multi-user environment. Locking 
prevents the common problem of lost updates from multiple users updating the same record. 



Solution Options 

Pessimistic Locking 

This policy of locking allows the first user to have full access to the record while following users 
are denied access or have read only access until the record is unlocked. There are drawbacks to 
this method of locking. It is a method that is prone to deadlocks on the database as well poor 
performance when conflicts are encountered. 

Optimistic Locking 

The optimistic approach to record locking is based on the assumption that it is not normal 
processing for multiple users to both read and update records concurrently. This situation is 
treated as exceptional processing rather than normal processing. Locks are not actually placed 
on the database at read time. A timestamp mechanism is used at time of update or delete to 
ensure that another user has not modified or deleted the record since you last read the record. 

A preferred embodiment of the present invention uses an optimistic locking approach to 
concurrency control. This ensures database integrity as well as the low overhead associated with 
this form of locking. Other benefits to this method are increased availability of records to 
multiple users, and a minimization of database deadlocks. 

Table candidates for concurrency control are identified during the "Data Modeling Exercise". 
The only table which is updated concurrently is the Optimistic Locking mechanism. Once these 
are identified, the following is added to the application. 

Add "N_Last_Updt" field to table in database; 
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Error Handling routines on those operations which modify or delete from this table; and 
Display/Notification to user that the error has occurred. 
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Usage 

The chart below describes the roles of the two basic types of components to enable optimistic 
locking. 

Assumption: The optimistic locking field is of type Date and is named "N_Last_Updt 



Read 
Access 


Store NJLast_Updt value in the 
business object for use in possible 
updates or deletes. 


_ Server Components 

Retrieve data (Always including NLastUpdt field). 

SELECT Id, FirstName, N Last Updt 
FROM Customer 
WHERE id = 10; 


Inserts 


Normal 


Dim lCurrTS As Double 
ICurrTS = GetTimeStamp 

INSERT INTO Customer (Id, FirstName, N Last Updt) 
VALUES (1, "Rick", ICurrTS); 

Return new timestamp (ICurrTS) as well as new Id 


Updates 


Pass previously read timestamp to 
identify whether row was modified. 
This is in addition to a unique identifier 
and whatever data needs to be updated 

Handle exception if record has been 
previously modified 

Notify user of conflict. 

Rollback any changes. 


Dim ICurrTS As Double 
ICurrTS = GetTimeStamp 

UPDATE Customer 

SET firstName = "Richard", 

N Last Updt = ICurrTS 
WHERE id=l 

AND LastUpdate = lastReadTimestamp; 

If no rows are affected, handle and propagate error back 
out to the client 

Return new timestamp (ICurrTS) 


Deletes 


Pass previously read timestamp to 
identify whether row was modified. 
This is in addition to a unique identifier 

Handle exception if record has been 
previously modified 

Notify user of conflict. 

Rollback any changes. 


DELETE Customer 
WHERE id = 1 

AND N Last Updt = lastReadTimestamp; 

If no rows are affected, handle and propagate error back 
out to the client. 



LARGE RESULT SF.T 



When retrieving records from a database, if the search criteria is too broad, the amount of data 
required to be retrieved from the database and passed across the network will affect user 
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perceived performance. Windows requesting such data will be slow to paint and searches will be 
slow. The formation of the database queries is made such that a workable amount of data is 
retrieved. There are a few options for addressing the problems that occur from large result sets. 
The options are given below in order of preference. 

Redesign the interface/ controller to return smaller result sets. By designing the controllers that 
present the database queries intelligently, the queries that are presented to the database server do 
not return a result set that is large enough to affect user perceived performance. In essence, the 
potential to retrieve too many records indicates that the UIs and the controllers have been 
designed differently. An example of a well designed Search UI is one where the user is required 
to enter in a minimum search criteria to prevent an excessively large result set. 

Have Scrollable Result Sets. The scrolling retrieval of a large result set is the incremental 
retrieval of a result subset repeated as many times as the user requests or until the entire result set 
is obtained. Results are retrieved by the Bounded Query Approach where the first record is 
determined by a where clause with calculated values. 

Scrollable Result Set Client requirements 

Preferred UI 

The preferred displays are as follows: 

Returned results are displayed in a GreenTree List Box; 

An action button with the label More... is provided for the user to obtain the remaining results; 

The More button is enabled when the user has performed an initial search and there are still 
results to be retrieved; 

The More button is disabled when there are no more results to retrieve; 
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The List Box and the Action button is contained within a group box to provide a visual 
association between the button and the List Box. 



Bounded Query 

Queries that are implemented with the limited result sets are sent to the server. The server 
implements the executeQuery method to retrieve the recordset as usual. Limited result queries 
have an order by clause that includes the business required sort order along with a sufficient 
number of columns to ensure that all rows can be uniquely identified. The recordset is limited by 
the nMaxRows variable passed from the client incremented to obtain the first row of the next 
result set. The return from the component is a recordset just the same as with a query that is not 
limited. The CCA 208 creates the objects and passes these back to the controller 206 . The 
Controller 206 adds this returned collection of object to its collection of objects (an accumulation 
of previous results) and while doing so will performs the comparison of the last object to the 
first object of the next row. The values necessary to discriminate the two rows are added to the 
variant array that is necessary to pass to the component for the subsequent query. 

The Controller 206 on the client retains the values for nMaxRows, the initial SQL statement, and 
array of values to discern between the last row of the previous query and the first row of the next 
query. The mechanism by which the controller 206 is aware that there are more records to 
retrieve is by checking the number of results is one greater than the max number of rows. To 
prevent the retrieval of records past the end of file, the controller 206 disables these functions on 
the UI. For example, a command button More on the UI, used to requested the data, is disabled 
when the number of objects returned is less than nMaxRows + 1 . 



Application responsibility 

Server 

The Server component is responsible for creating a collection of arguments and 
appending the SQL statement to add a where clause that will be able to discriminate between the 
last row of the previous query and the first row of the next. 

CCA 

The CCA 208 processes the recordset into objects as in non limited queries. The CCA 
208 forwards the variant array passed from the Controller 206 to identify the limited results. 
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Controller 

The controller 206 has the responsibility of disabling the More control when the end of 
file has been reached. The controller 206 populates the variant array (vKeys) with the values 
necessary to determine start of next query. 

Example 

A CCA 208 is coded for a user defined search which has the potential to return a sizable 
result set. The code example below implements the Bounded Query approach. 



On the Server the developer codes the query as follows: 



Public Function Retrieve Business Objects (vMsg As Variant, ByVal sSql As String. ByVal nMaxRows As 
Integer, Optional ByVal vKeys As Variant) As Recordset 
On Error GoTo BrrorHandler 

'Declare local constants 

Const cmMethodName As String = • Re trieveBusinessOb jeers" 



•Declare local variables 

Dim cmClassName As String 

Dim colArgs As New CCol lection 

'initialize instance variables 
cmClassName = ,, CSRSTestComp ,1 



'fill argument collection 

Set colArgs = Arguments For Bus inessObject (vKeys , sSQL) 
■ increment nMaxRows to obtain row for comparison 
nMaxRows = nMaxRows + 1 
* ExecuteQuery 

Set RetrieveBus inessObject s = ExecuteQuery (vMsg, croSelect Local, sQuery, nMaxRows, , 

colArgs) 



•Tell MTS we're done 

GetOb jectContext . SetComplete 

Exit Function 

ErrorHandler : 

Select Case Err. Number 

Case Else 

Dim iResumeCode As Integer 

iResumeCode » GeneralErrorHandler<vMsg. cmServer, cmClassName, cmMethodName) 
Select Case iResumeCode 
Case cmErrorResume 

Resume 
Case ctnErrorResumeNext 

Resume Next 
Case cmErrorExit 

Exit Function 
Case Else 
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GetObject Context .Set Abort 
Err. Raise Err. Number 
End Select 
End Select 
End Function 



To determine the additional where clause necessary to determine the starting point of the query, 
the following method is added: 

Private Function Argument sForBusineasObject (vKeys As Variant, sSql As string » As Collection 
Dim colArgs As Ccollection ^oneccian 

Const cxnGreaterThanWhereString As String =«?>?« 

Const cmGreaterThanOrEqualWhereString As String =*?>=? AND ■ 

initialize local variables 
Set colArgs New Ccollection 
sSql « sSql ♦ "WHERE* 



With colArgs 

If vKeys (0) <> Empty Then 

-Add ( * N__T AS K_TEM P L_ ID" ) 
.Add ( vKeys (0) ) 



End If 

•If vKeys (I) <> Nothing Then 
• .Add value2 fieldName 
'-add vKeys(l) 

sSql = sSql + cmGreaterThanOrEqualwhe rest ring 
'End If 

•If VKeys (2) <> Nothing Then 
'.Add value3 fieldName 
1 -add vKeys {2) 

sSql = sSql + cmGreaterThanOrEqualwhereString 
'End If 
End With 



'finalize SQL statement 

sSql = sSql + cmGreaterThanWhereString 

Set ArgumentsForBusinessObject * colArgs 
End Function 



On the CCA 208, allowance must be made for the passing of the vKeys 

Public Function RetrieveBusinessObjects(vMsg As Variant, sSql As String, nMaxRows As 
Integer, Optional ByVal vKeys As Variant) As CCoIlection 

Set percmpComponent = New CSRSTestComp 
Dim i As Integer 



Set adoRS s 



percmpComponent. RetrieveBusinessOb jects (vMsg. sSql, nMaxRows, vKeys) 
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•convert recordset to business objects 
adoRS . MovePirst 
Do Until adoRS . EOF 

Call ConvertToBusinessObject 

adoRS . MoveNext 

Loop 

•return the collection of business objects 

Set RetrieveBusinessObjects - dictBusinessObject 

Set dictBusinessObject = New CCollection 

End Function 

The controller initiates the query and updates the variant array of keys and form 204 properties 
based on the return. In addition to the code shown for the example below, the More Control is 
enabled if the search is cleared. 

•declare instance variables 
Private nMaxRows As Integer 
Dim interimRe suits As CCollection 
Dim vRe suits As CCollection 
Dim vKeys(3) As Variant 

•declare Constants 

Private Const nDef aultAmount As Long =50 

Private Const cmRetrieveBusinessObjectSQL = "SELECT * FROM NODE_RULE ORDER BY _ 
N__T AS K_TEMPL_ ID ■ 

During class initialization perform the following: 

Public Sub Class_init() 

'obtain settings from registry 

nMaxRows = CInt (GetSetting (craRegApp, cmRegArchSection, craLimitedResultAmountKey , 
1 Default Amount) ) 

Call reset Search 

Set objCCA = New { CCA class name) 
End Sub 

Search reset functionality is kept outside of initialization so this may be called from other parts 
of the application. 

Public Sub resetSearch ( ) 
Dim I as Integer 

Set vResults = New Ccol lection 
For 1=0 To 3 

Set vKeys(I) = Empty 
Next 

Set vKeys(O) = Empty 
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f rmCur rent Form. cmdMo re. Enabled = True 

End Sub 



Public Sub RetrieveBusinessObjectsO 

Const cmMethodName As String = TetrieveBusinessObjects" , 

Call RetainMouse 



' get arch message 
Dim vMsg As Variant 

vMsg = objApp.objArch.AsMsgStructO 

1 call the component 
Dim pair As CArchPair 



•Declare local variables 
Dim sSql As String 
Dim colArgs As CCollection 
Dim cmClassNarae As String 

ctr = ProcessObjectCol lection 

•stop if size of return is less than the maximum 

If ctr < nMaxRows + 1 Then fnnCur rent Form. cmdMore . Enabled = False 
' restore pointer 
Screen. Mouse Pointer => lPrevPtr 
End Sub 

In order to retain the values to discriminate between the last row of the result set and the first row 
of the next the following method on the controller is used: 



Private Function ProcessObjectCollection ( ) As Integer 

• merge results with the instance variable for the collection 
Dim ctr As Integer 
ctr = o 

For Each element In inter imResults 
ctr = ctr ♦ 1 

•retain Keys for subsequent Queries 
With element 
Select Case ctr 
Case nMaxRows 

'store all values that may be used for row comparison 
vKeys(O) = .Node Id 



•add last object to collection 
vResults.Add element 



Case nMaxRows + 1 

'last object only used for comparison 

■If the proceeding value can be used to uniquely 

•identify row then delete value from array 
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■ THERE SHOULD BE N • 1 nested If statements where N = size of vKeys 
•If .value2 <> vKeys(l) Then 
•vKeys(2) = Empty 

If .Nodeld <> vKeys(O) Then vKeys(l) = Empty 
•End If 
Case Else 

vResults.Add element 

End Select 
End With 

Next 

ProcessObjectCol lection = ctr 
End Function 



Operation of example with data 



Person 



First Name 


Last Name 


Status 


Unique ID 


Joy 


Andersen 


Closed 


22 


Jay 


Anderson 


Open 


12 


John 


Barleycorn 


Closed 


512 


John 


Barleycorn 


Open 


32 


Esther 


Davidson 


Open 


88 


David 


Dyson 


Closed 


98 


Bobby 


Halford 


Open 


234 


Steven 


Jackowski 


Closed 


4 


Kyle 


Johnsen 


Open 


65 


Jeff 


Johansen 


Open 


13 


Mary 


Johnson 


Closed 


24 


Larry 


Olsen 


Open 


21 


William 


O'Neil 


Closed 


29 


Jane 


Pick 


Open 


3285 



For this example let nMaxRows = 3. The business case calls for the result set to be ordered by 
the last name, and developer knows that any row can be uniquely identified by the FirstName, 
LastName, and Unique ID fields so the initial SQL added as a constant in the controller should 
be; 

SELECT * FROM Person ORDER BY LastName, FirstName, Unique_ID 
Initial Query 

The first query is sent with an empty vKeys Array. When the server receives this query, the 
method ArgumeotsForBusinessObject identifies the elements as being empty and does not 
populate the colArgs. The query is executed with the intial SQL unchanged. The recordset of 
size nMaxRows + I is returned to the CCA 208 and processed the same as non-limited results. 
The CCA 208 returns the collection of objects to the controller 206. The controller 206 proceeds 
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to populate the vResults collection with the returned objects. vResults is the comprehensive 
collection of objects returned. When the last object of the first request is reached (at nMaxRows), 
the values are stored in vKeys as such; 
vKeys(O) = LastName (Barleycorn) 
vKeys(l) = FirstName ( John ) 
vKeys(2) = Unique_ED (5 1 2) 

When the First Object of the next request is reached ( at nMaxRows +1), comparison of the 
object variables against the vKeys values is performed. Because the last names match, vKeys(2) 
will not be deleted and no further checks are performed. 
Subsequent Query 

The subsequent query will pass vKeys along with it. The server creates the collection of 
arguments from vKeys and append the sSql string in accordance. The sSql statement that is 
passed to execute query is 

SELECT * FROM Person ORDER BY LastName, FirstName, Unique^ID 

WHERE ? >= ? AND ? >= ? AND ? > ? 
This sSql and collection is included in the call to ExecuteQuery which merges the arguments 
with the string relying on the architecture method MergeSQL to complete the SQL statement. 
The starting point of the recordset is defined by the WHERE clause and the limit is set by the 
nMaxRows value. 

Query less restrictive WHERE criteria 

After the second query the last row of the query is David Dyson and the next is Bobby 
Halford. Because the last name is different, vKeys will be empty except for vKeys(O) = Dyson. 
The ProcessObjectCollection will populate vKeys as follows when processing nMaxRows 
object: 

vKeys(0) = LastName (Dyson) 
vKeys(l) = FirstName (David) 
vKeys(2) = Unique JD (98) 

After identifying the differences between vKeys values and the nMaxRows + 1 object the vKeys 
array is updated as follows: 
vKeys(0) = LastName (Dyson) 
vKeys(l) = Empty 
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vKeys(2) = Empty 

The query that is returned from ArgumentsForBusinessObject is 

SELECT * FROM Person ORDER BY LastName, FirstName, Unique_ID 
WHERE ? > ? 

and the colArgs possessing the fieldname FirstName and the value ("David")- ExecuteQuery 
merges the arguments with the sql statement as before and returns the value. 

Ending 

After the fifth iteration the result set will only possess 2 records. When the controller 206 
processes the returned collection the counter returned from ProcessObjectColIection is less than 
nMaxRows + 1 which indicates that all records have been retrieved. 



SECURITY FRAMEWORK 

Implementation 

Figure 8 shows a representation of the Security Framework 800 and its main components. 

It can be seen from Figure 8 that the Security object 802 is present at the Client and a Security 
API is provided at the server. The Security object 802 provides one method responsible for 
authorizing any operation, being given the vMsg structure, an operation ED and an optional 
parameter describing the operation's context. 

Client 
User Authentication: 

User authentication is handled via a method located in the Security object 802 called 
IsOperAuthorized. As the Application object loads, it calls the IsOperAuthorized method, with 
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the operation being "Login", before executing further processing. This method subsequently 
calls a authentication DLL, which is responsible for identifying the user as an authorized user 
within the Corporate Security. 

UI Controllers: 

The UI Controllers limit access to their functions by restricting access to specific widgets 
through enabling and disabling them. The logic for the enabling and disabling of widgets 
remains on the UI Controller 206, but the logic to determine whether a user has access to a 
specific functionality is located in the Security object 802 in the form of business rules. The UI 
Controller 206 calls the IsOperAuthorized method in order to set the state of its widgets. 

Server 

Server security is implemented by restricting access to the data in three different ways: 
Server Security Method 

Server Components 222 call the IsOperAuthorized API in the Architecture before executing 
every operation. In all cases the Security object 802 returns a boolean, according to the user's 
access rights and the business rules 

SQL Filtering 

Includes security attributes, like claim sensitiveness or public/private file note, into the SQL 
statements when selecting or updating rows. This efficiently restricts the resulting data set, and 
avoids the return of restricted data to the client. 

Description 

Any GUI related security is implemented at the Client using the Security object 802. The 
information is available both at the Client Profile and Business Objects 207 which enables the 
security rules to be properly evaluated. 

IsOperAuthorized is called to set widgets upon the loading of a UI or if there is a change of state 
within the UI. 
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User authentication always is used by the Application Objects 202 in order to validate user 
privilege to launch the application. 

SQL Filtering is used in the cases where sensitive data must not even be available at the Client, 
or where there is a great advantage on reducing the size of the data set returned to the Client. 

SQL Filtering is only used in very rare cases where performance is a serious concern. It is used 
carefully in order to avoid increased complexity and performance impacts because some queries 
can be cumbersome and embedding security on them could increase complexity even more. 

Security Framework 

Overview 

The Security object 802 serves the purpose of holding hard coded business rules to grant or deny 
user access for various application functions. This information is returned to the UI controllers 
206 which make the necessary modifications on the UI state. The ClientProfile object serves the 
purpose of caching user specific (and static) security information directly on the client. This 
information is necessary to evaluate the business rules at the Security object 802. 

Relationships 

Figure 9 shows the relationships between the security element and other elements. 
Architecture Object 

The TechArch object is responsible for providing access and maintaining the state of the 
ClientProfile 902 and Security objects 802. The ClientProfile object 902 is instantiated and 
destroyed in the TechArch's initialization and terminate methods, respectively. This object is 
maintained through an instance variable on the TechArch object. 
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CInitCompCCA 

The CInitCompCCA object 904 provides two services to the architecture object 200, it serves as 
an access point to the CInitComp Server 906, and it Marshalls the query result set into a 
ClientProfile object 902. 

CInitComp 

The CInitComp server object 906 provides data access to the data that resides in the organization 
tables 908. This data is useful on the client to determine level of access to data based on hard 
coded business rules. 

Organization Tables 

The Organization tables 908 contain user, employee and unit information necessary to build the 
hierarchy of infonnation necessary to determine level of access to sensitive information. 

ClientProfile 

The ClientProfile object 902 serves the purpose of caching static, user specific security 
information directly on the client. This information is necessary to determine data access level 
of information to the user, which is accomplished by passing the necessary values to the Security 
object 802. 



Security Object 

The Security Object 802 contains business rules used to determine a user's access privileges in 
relation to specific functions. The object accepts certain parameters passed in by the various UI 
Controllers 206 and passes them to through the business rule logic which, in turn, interrogates 
the Client Profile object 902 for specific user information. 

Client Profile 

Attributes 

The following are internal attributes for the Client Profile object 902. These attributes are not 
exposed to the application and should only be used by the Security object 802: 
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sProfile: 

This attribute is passed by the legacy application at start-up and contains the user's TSIds, 
External Indicator, Count of Group Elements and Group Elements. It is marshalled into these 
attributes by request of the application objects. 

colSpecialUsers: 

This attribute caches information from a table containing special users which do not fit into 
one of the described roles, such as Organization Librarian, (e.g., Vice President or CEO of 
the corporation.) 

) 

sTSId: 

This is the current users* TSId, and it corresponds to his/her Windows NT Id. It is used to get 
information about the current logged on user from the Organizational Tables 908. 



sEmployeeld: 

This corresponds to the user's employee Id, as stored in the Organizational tables 908. It is 
used against the passed in employee Id, in order to check relationship between performers 
and the current user. 

sEmployeeName, sEmployeeFirst, sEmployeeMI and sEmployeeLast: 
All these attributes correspond to the current user's name. 
dictCHentPrivileges: 
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This attribute contains a collection of identifiers that indicate what role/authority an 
individual plays/possesses. This value is used to identify the static role of the logged in user. 



These values are used for security business logic which grants or denies access based on 
whether the user is internal or external, or whether the user is in a given administrative role. 
Existing values are the following: 

• SC - Indicates sensitive Claim authority 

• CC - Indicates Change Claim status authority 

• MT - Indicates maintain F&C Templates authority 

• MO - Indicates maintain Organization authority 

• MR - Indicates maintain Roles authority 

The following are the proposed additions: 

• TA - Indicates authority to execute Task Assistant 

• FN - Indicates authority to execute FileNotes 

• CH- Indicates authority to execute Claim History 

• TL - Indicates authority to maintain Task Templates 

dictProxyList: 

This attribute contains an employees* reporting hierarchy. It is used to determine whether 
the current user/employee has permission to perform some action based on his/her 
relationship to other users/employees within their hierarchy. A business example of this is 
the case of a supervisor, who has rights to view information that his/her subordinates have 
access to. The relationship APFs make use of dictProxyList to determine if the user assigned 
to the information is super or subordinate of the current user. 

boollnternal: 

This attribute indicates whether the logged in user is external or internal. It is also marshalled 
from the sProfile attribute, passed in by the legacy application. 
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Public Methods 

The following are the APIs exposed by the Client Profile object. These APIs are used for 
security checking by the Security object and should not be used by the developers in any portion 
of the application. 

5 

• GetAuthorizedEmployees As Collection 

This function returns a collection of employee Ids from the employees supervised by the 
current user. 

IsSuperOf(sUserId) As Boolean 

This API returns true if the logged in user is a super of the passed in user Id. It looks up the 
sUserld value inside the dictProxyList attribute. 

IsRelativeOflsUserld) As Boolean 

This API returns true if the passed in user Id corresponds to either the logged in user or 
someone from the dictProxyList. 

Islntemal As Boolean 

This API is used to grant or restrict the user to information based on whether the data is 
private to the organization whether the user is internal or external. 

IsInRole(sRole) As Boolean 

This API looks up the appropriate sRole value contained within the dictClientRoles attribute 
to determine whether the current user is authorized to perform that role. 
30 

The following accessors are used to get data from the Client Profile's object: 

• Userld: returns sTSId 

• Employeeld: return sEmployeeld 
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• EmpIoyeeName: returns sEmployeeName 

• EmployeeFirstName: returns sEmployeeFirst 

• EmpIoyeeLastName: returns sEmployeeLast 

• EmployeeMiddlelnitial: returns sEmployeeMI 

• ExpandTree: returns boolExpandTreePreference 

• TemplatePathPreference: returns sTemplatePathPreference 



Security Object 

Public Methods 

The following API is exposed by the Security Object and is used by the application for security 
checking: 



• IsOperAuthorized(vMsg As Variant, nOperations As cmOperations, vContext As Variant) 
as Boolean 



This API will return true or false depending on what is returned from the business rule 
functions to determine user access levels. This API is called on two situations: 

1 . When setting the initial state before loading the form. If a security requirement exists, 
IsOperAuthorized is called for the appropriate operation. 

2. After any relevant change on the UI state. For example, when a sensitive claim is 
highlighted on the Task Assistant window. A relevant change is one which brings the 
need for a security check. 

The valid values for the enumeration and the correspondent context data are: 

■ cmMaintainFormsCorr (none) 

■ cmRunEventProcessor (none) 

■ cmWorkOnSensitiveClaim (a Claim object) 

■ cmMaintainPersonalProfile (none) 

■ cmMaintainWorkplan (none) 
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■ cmDeleteFileNote (a File Note object) 

■ cmMaintainTaskLIbrary (none) 
• cmMaintainOrg (none) 

Server Security APIs 

• IsSVCOperAuthorized(vMsg As Variant, sOperations As String , vContext As Variant) as 
Boolean 

This API is called by every method on the server that persists data or can potentially access 
sensitive data (reactive approach). 

■ IsOperAuthorized(vMsg As Variant, nOperations As cmOperations, vContext As Variant) as 
Boolean 

This API is available for those cases where a proactive security check is needed on the 
server. 

Implementation Examples 

The following examples show some ways to implement the options described above: 
Client 

• Business Logic 
IsOperA uthorized 

Let's consider the case of the Task Assistant window, where the user should not be allowed 
to view any information on a sensitive claim if he/she is not the claim performer or the 
performer's supervisor. The following code would be at the Controller: 
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Private Sub TaskTree_NodeChanged ( . . . . ) 

myController . Set Current Task 

myCont roller . Set State 
End Sub 

Private Sub SetStateO 

Dim obj Security as Object 
Dim vContext(l) as Object 

Set objSecurity = taaApp, taoArch. obj Security 

vContext(O) = CurrentClaira 
vContext(l) = CurrentTask 

tlbEdit I con. Enabled = 

obj Security . I sOper Authorized { vMsg, cmWorkOnSensitiveClaim, vContext) 

End Sub 

Let's consider the case of the Maintain Correspondence Search window where only a user 
who is a Forms and Correspondence Librarian should be allowed to delete a template. The 
following code would be at the Controller: 

Private Sub SetWindowMode ( ) 
Dim objSecurity as Object 

Set objSecurity = taaApp. taoArch. obj Security 

tlbEditlcon. Enabled = objSecurity . I sOper Authorized (vMsg. cmMaintainFormsCorr) 
End Sub 

Server 

• SQL Filtering: 

Let's consider the example of the Draft File Note window, where a user can only look at the 
draft file notes on which he/she is the author At the controller, one would have: 

Public Sub GetDraftFNotesO 
Dim obj CP as Object 

Set objCP = taoArch. obj Client Profile 
Dim fntCCA as Object 

Set fntCCA = taaApp.taoArch.GetCCA(cmCCAPileNote) 



116 



WO 00/67186 



PCT/USOO/12508 



Call fntCCA.CetADraftFHotetvMsg, objCP . sOrgUserld, colFNotes) 
End Sub 

And at the Component, the SQL statement would be: 

Select nFNoteld, 
s FNo t eAu t ho r , 
dFNoteFinal, 

From File Note 

where sFileNoteSts » 'D' 

And sFNoteAuthor - s Author 

Task Engine Application 

This application runs on the server as a background process or service with no direct interaction 
with Client applications, so it doesn't need any GUI related security. Basically, its main actions 
are limited to the generation of new tasks in response to externally generated events or, more 
specifically, it: 

• Reads static information from the Task Template tables; 

• Reads events from the Event tables; 

• Inserts tasks on the Task table. 

In this sense, its security is totally dependent on external entities as described below: 

• The Task Library application is the entrance point for any changes on the Task Template 
database tables. It will make use of the options described above in order to fulfill its 
security requirements. 

• Events are generated from legacy applications, so the Task Engine relies completely on 
the security implemented for these applications in order to control the generation of 
events. 

• Another level of security for event generation relies on the Database authorization and 
authentication functions. Only authorized components have access to the database tables 
(this is valid for all the other applications as well). 
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Definition 

The Claim Folder manages claim information from first notice through closing and archiving. It 
does this by providing a structured and easy to use interface that supports multiple business 
processes for handling claims. The information that it captures is fed to many other components 
that allow claims professionals to make use of enabling applications that reduce their workload. 
Because physical claim files are still required, the claim folder provides capabilities that support 
physical file tracking. It works with the LEGACY system to support all the capabilities that 
exist within the current system. 



The primary processes supported by the Claim Folder 



are: 



First Notice of Loss 

The Claim Folder is the primary entry point for new loss information. Claim files exist in 
the Claim Folder before they are "pushed" to the LEGACY system to perform financial 
processing. 
Claim Inquiry 

Claim Folder supports internal and external inquires for claim information. The folder 
design allows quick access to various levels of information within the claim for many 
different reasons. 

Initiation of Claim Handling 

The Claim Folder provides initial loss information to the claim professional so they may 
begin the process of making first contacts with appropriate participants in the claim. It 
allows them to view and enter data received through their initial contacts and 
investigation. 

Investigation and Evaluation 

The Claim Folder provides access to detailed information needed for the investigation 
and evaluation process. It allows the claim handler to navigate between all the 
applications and information they need to support these processes. 

Identifying Claim Events 
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The Claim Folder identifies critical events that occur in the life of a claim, such as a 
change of status, which can trigger responses in other components to perform automated 
functions, like triggering tasks in the Task Assistant. 
• Managing the Physical File 

The Claim Folder supports better tracking capabilities for the physical files that go along 

with the electronic record of a claim. 



Value 

By capturing detailed information on claims, the Claim Folder tries to improve the efficiency of 
claim professionals in many ways. First, because the information is organized in a logical, easy 
to use format, there is less digging required to find basic information to support any number of 
inquiries. Second, the Claim Folder uses its information to support other applications like Forms 
and Correspondence, so that claim information does not have to be reentered every time it is 
needed. Third, it provides better ways to find physical files to reduce the time required finding 
and working with them. Beyond this, there are many other potential uses of claim folder 
information. 

The Claim Folder also tries to overcome some of the current processing requirements that the 
LEGACY system imposes such as recording losses without claims, requiring policy numbers for 
claim set-up, requiring reserves for lines, and other restrictions. This will reduce some of the 
low-value added work required to feed the LEGACY system. 

Finally, the Claim Folder organizes and coordinates information on participants and performers 
so that all people involved in a claim can be identified quickly and easily. 



Key Users 

Although claim professionals are the primary users of the Claim Folder, any claims professional 
can utilize the Claim Folder to leam about a claim or answer an inquiry about a claim. 



119 



WO 00/67,86 PCT/USOO/12508 
Component Functionality 

Because the Claim Folder is the primary entry point for new claims, it needs to capture 
information necessary to set-up new claims and be able to pass the information to the LEGACY 
system. Once the information is passed, the LEGACY system owns all information contained in 
both systems, and it is uneditable in the Claim Folder. However, the Claim Folder has more 
information than what is contained in the LEGACY system, and therefore allows certain 
information to be entered and modified once the claim is pushed to the LEGACY system. 

The Claim Folder decomposes a claim into different levels that reflect the policy, the insured, the 
claim, the claimants, and the claimant's lines. Each level has a structured set of information that 
applies to iL For example, the claim level of the claim has information on the claim status, line 
of business, and performers. An individual line has information which includes the line type, 
jurisdiction, and property or vehicle damages. The claimant level contains contact information 
as well as injury descriptions. 

The information at each level is grouped into sections for organization purposes. Each level has 
a details section that includes the basic information about the level. 

The key levels on the Claim Folder and their information sections are: 



• The Policy Level- Details and Covered Auto for auto claims, Covered Property for 
property claims and Covered Yacht for marine claims. 

• The Claim I^vel: Details, Facts of Loss, Events, Liability. Liability is considered part of 
the Negotiation component and described there. 

• The Participant T,evel Details and Contact Information. For claimants, additional 
sections are shown to display, Events, Injury and Disability Management. The 
participant level is discussed in the Participant Component. 

• The Line Level; Details, Damaged Vehicle for vehicle lines, Damaged Property for 
property lines, Damaged Yacht for marine lines, Events, Damages, and Negotiation. 
Damages and Negotiation are considered part of the Negotiation component and 
described there. 
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Events are triggered in the Claim Folder by performing certain actions like changing a 
jurisdiction, identifying an injury, or closing a line. Other general events are triggered in the 
Event Section on most levels by clicking the one that has occurred. These events are processed 
by the Event Processor and could generate any number of responses. In one embodiment of the 
5 present invention, the primary response is to trigger new tasks in the Task Assistant for a claim. 

User Interfaces 

• Claim Folder UI 

10 • Policy Level - Policy Details Tab 

• Policy Level - Covered Vehicle Tab 

• Policy Level - Covered Property Tab 

• Policy Level - Covered Yacht Tab 

• Claim level - Claim Details Tab 
15 • Claim level - Facts of Loss Tab 

• Claim level - Events Tab 

• Claim level - Liability Tab 

• Line level - Line Details Tab 

• Line level - Damaged Property Tab 
20 • Line level - Damaged Auto Tab 

• Line level - Damaged Yacht Tab 

• Line level - Events Tab 

• Line level - Damages Tab 

• Line level - Negotiation Tab 
25 • Task Assistant 

• File Notes 

• Claim History 

• Search Task Template 

• Search for Correspondence 
30 • Find Claims 

• Version 7 

• View File Folder 
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• Print Label 



5 CLAIM FOLDER TREE AND MENU DESIGN 

Claim Tree 

The claim tree in the Claim Folder window decomposes the claim into policy, insured, claim, 
claimant, and line levels depending on the specific composition of the claim. 

10 

The policy level is always the first node in the claim tree and is identified by the policy number. 
Before the policy number is entered, the field is listed as "Unknown". If a claim is uncoded, the 
field is listed as "Uncoded". Selecting the policy level brings up the policy level tabs in the body 
of the Claim Folder. 

15 

The insured level is always the second node in the claim tree and is identified by the insured's 
name. Before the insured is identified, the field is listed as "Unknown" Selecting the insured 
level brings up the insured participant tabs in the body of the claim folder. Only one insured is 
listed at this level as identified in the policy level tabs, however, multiple insureds can still be 
20 added. Additional insureds are shown in the participant list below the claim tree. 

The claim level is always the third node in the claim tree and is identified by the claim number. 
When the claim level is selected, the claim level tabs appears in the body of the Claim Folder. 

25 After the claim level, all claimants are listed with their associated lines in a hierarchy format. 

When a claimant is added, a node is added to the tree, and the field identifying the claimant is 
listed as "Unknown". Once a participant has been identified, partial or client, the name of the 
claimant is listed on the level. When the level is selected, the participant level tabs for the 
claimant is shown in the body of the claim folder. 

30 

Line levels are identified by their line type. Before a line type is selected, the line level is listed 
as "Unknown". When a line level is selected, the line level tabs for the specific line are shown in 
the body of the claim folder. 
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There are several things that can alter the claim tree once it has been set up. First, if a claimant 
or line is deleted, it is removed from the claim tree. A claim that is marked in error does not 
change the appearance of the levels. Second, the claim, claimant, and line levels are identified 
by different icons depending on whether they are pushed to V7 or not. Third, when a line or 
claimant is offset, it is identified as such. 

Participant List 

The participant list box contains all the non-claimant and non-insured participants on the claim. 
(Claimants and insureds are shown in the claim tree and not repeated here.) Participants are 
shown with their name and role. When a participant is selected, the participant level tabs are 
displayed in the claim folder. 

Claim Folder Menu Items 

The claim folder menus contain the actions that a user would need to perform within the claim 
folder. They can all be accessed through keyboard selection. The menu options become enabled 
or disabled based on the state of the Claim Folder. The Claim Folder can be in view mode or 
edit mode for a specific level in the Claim Tree. When the Claim Folder is in edit mode, most 
options are disabled until the user saves their changes and is returned to view mode. The 
enabling/disabling of menu options is also dependent on whether the claim or portions of the 
claim have been pushed to V7. 

Claim Folder Tool Bar 

The tool bar represents common action that a user performs that can be easily accessed by 
clicking the appropriate icon. There are five groups of button on the Claim Folder tool bar that 
represent, in order, common activities, adding new items to a claim, launching utilities, 
performing V7 activities, and accessing help functions. The enabling/disabling of tool bar 
buttons follows the same logic as for menu items. 



Window Description 
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Claim Tree 



Tree View 



Participant List 



List View 



Edit Tool Bar Button Command Button 



Refresh Tool Bar 
Button 



Command Button 



Find Tool Bar Button Command Button 



Claim Allocation 
Tool Bar Button 

Manage Physical File 
Tool Bar Button 

Declare Event Tool 
Bar Button 

Claimant Tool Bar 
Button 



Command Button 



Command Button 



Command Button 



Command Button 



Participant Tool Bar 
Button 



Command Button 



Line Tool Bar Button Command Button 



The Claim Tree lists the 
policy, insured, all of 
the claimants and their 
related lines in a claim 
tree format. 



A list of all non-insured 
and non-claimant 
participants associated 
with a claim. 



Changes the tabs for the 
level selected in the 
claim tree or participant 
list view to edit mode. 
Refreshes the current 
claim, including all 
Participant and Line 
information. 
Opens the Claim Search 
window to allow the 
user to search for 
another claim 
Opens the Claim 
Allocation window. 

Opens the Manage 
Physical File window. 

Opens the Declare 
Events window. 

Adds claimant and 
opens Participant tabs in 
edit mode for entry of a 
new claimant level node 



Adds a new participant 
and opens Participant 
tabs in edit mode. 
Adds line and opens 
Line tabs in edit mode 
for entry of a new line 
level node. 
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The current claim 
tree structure for 
the selected 
claim. The claim 
level is selected 
and the claim 
level tabs are 
displayed. 
All participants 
who are not 
claimants or 
insureds for the 
claim and their 
roles 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled 



Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. V7 limit 
for claimants is 
999, we will not 
edit this here. 
Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode and 
claimant context 
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Assign Performer 
Tool Bar Button 

Print Screen Tool Bar 
Button 

Task Assistant Tool 
Bar Button 

File Notes Tool Bar 
Button 

Claim History Tool 
Bar Button 

Correspondence Tool 
Bar Button 

Push to V7 Tool Bar 
Button 



Command Button 

Command Button 
Command Button 

Command Button 

Command Button 

Command Button 

Command Button 



Make Payment Tool Command Button 
Bar Button 



Help Tool Bar Button Command Button 
Claim | Edit Menu Option 



Claim I Refresh 



Menu Option 



Opens Assign Performer 
window 

Prints the current claim 
folder window. 
Launches Task Assistant 
for the current claim 

Launch File Notes for 
the current claim 

Launch Claim History 
for the current claim 

Opens Forms and 
Correspondence window 

Open the terminal 
emulator window at the 
first V7 setup screen. 



selected in claim 
tree. V7 limit for 
lines is 15 per 
claimant, this 
button will be 
disabled after 1 5 
added. 

Enabled when 
claim is in view 
mode. 
Enabled 



Open the V7 PUEM 
screen in the terminal 
emulator window if a 
claimant or participant 
tied to one claimant is 
selected. Otherwise, 
display window that 
requires user to select a 
claimant. 
Opens Help 

Changes Claim tabs into 
Edit mode so that the 
user can make changes 
Refreshes the current 
claim, including all 
Participant and Line 
information. 



Enabled when 
claim in view 
mode. 

Enabled when 
claim in view 
mode. 

Enabled when 
claim in view 
mode. 

Enabled when 
claim in view 
mode. 

Enabled when 
claim is in view 
mode and claim 
status is pre-push 
or open and there 
are new claimants 
or lines to push. 
Enabled when 
claim had been 
pushed to V7 and 
a participant is 
selected. 



Enabled 
Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 
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Claim | Find 
Claim I Save 



Menu Option 
Menu Option 



Claim | Claim Status | Menu Option 

First Report 

Complete 



Claim | Claim Status | Menu Option 

Assignment 

Complete 



Claim | Claim Status | Menu Option 
Close 



Claim | Claim Status | Menu Option 
Reopen 



Claim | Claim Status | Menu Option 
Mark In Error 



Claim | Allocate Menu Option 



Claim | Manage 
Physical File 



Menu Option 
Claim | Declare Event Menu Option 



Claim | Close Claim Menu Option 
Folder 
Edit I Cut 



Edit | Copy 
Edit | Paste 



Menu Option 
Menu Option 
Menu Option 



Opens the Claim Search 
window 

Save the claim level 
when it is in edit mode. 

Changes the status of 
the claim to 
"Unassigned" and 
creates First Report 
Complete Event. 
Changes the status of 
the claim to "Open" and 
creates Assignment 
Complete Event. 

Initiates the close claim 
process 



Changes the status of 
the claim to "Open". 



Marks the current claim 
and all of its lines in 
error. Expires all 
participants. 
Opens the Claim 
Allocation window. 

Opens Physical File 
window 

Opens Declare Event 
window 

Closes current claim 

folder window 

Move selected text to 

the clipboard 

Copy selected text to the 

clipboard 

Paste text from the 



Enabled 

Enabled when the 
claim level is in 
edit mode. 
Enabled when 
claim is in view 
mode and claim 
status is "New". 

Enabled when 
claim is in view 
mode and claim 
status is 
"Unassigned". 
Enabled when 
claim is in view 
mode, V7 claim 
status is closed, 
and Millennium 
Claim Status is 
not "Closed" or 
"Archived" 
Enabled when 
claim is in view 
mode and 
"Closed" or 
"Archived". 
Enabled when 
claim is in view 
mode, and not 
pushed to V7. 
Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 
Enabled 

Disabled 

Disabled 

Disabled 
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clipboard 




View | 


Collapse AH 


Menu Option 


Collapses the claim tree 


Enabled 


View | 


Expand All 


Menu Cation 


Expand the claim tree 


Enabled 


Policy 


| Edit 


Menu Option 


Opens policy tabs in edit 


Enabled when 








mode. 


claim is in view 



Policy | Save 



Participant | New | 
Claimant 



Participant | New | 
Insured 



Participant | New | 
Other 



Participant | Edit 



Menu Option 
Menu Option 

Menu Option 

Menu Option 

Menu Option 



Participant | Save Menu Option 



Participant | Delete Menu Option 



Line I New 



Menu Option 



Line I Edit 



Menu Option 



Save current policy tab 
information. 

Opens Participant tabs 
in edit mode for entry of 
a new claimant level 
node in the claim tree. 
Opens Participant tabs 
in edit mode for entry of 
a new insured level node 
in the claim tree. 
Opens Participant tabs 
in edit mode for entry of 
a new entry in the 
Participant list. 
Puts currently selected 
participant tabs into edit 
mode. 



Saves information 
changed on participant 
tabs and returns claim to 
view mode. 
Deletes selected 
participant 



Adds new line to claim 
tree and opens line tabs 
in edit mode. 



Puts Line tabs into edit 
mode so that the user 
can change line details 



mode. 

Enabled when 
policy level is in 
edit mode. 
Enabled when 
claim in view 
mode. 

Enabled when 
claim in view 
mode. 

Enabled when 
claim in view 
mode. 

Enabled when 
claim is in view 
mode and 
participant 
selected in tree or 
list box. 
Enabled only 
when a 

participant level 
is in edit mode. 
Enabled only 
when claim is in 
view mode and 
participant is 
selected. 
Enabled when 
claim is in view 
mode, claimant 
has been selected, 
and limit of 15 
lines per claimant 
has not been 
exceeded. 
Enabled when 
claim is in view 
mode and line is 
selected. 
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Line I Save 



Menu Option 



Line | Change Status | Menu Option 
Close 



Line | Change Status | Menu Option 
Reopen 



Line | Change Status | Menu Option 
Mark in Error 



Line | Allocate Menu Option 

Performers | Assign Menu Option 

Performers | View All Menu Option 



Utilities | Print Screen Menu Option 
Utilities | View Task Menu Option 
Assistant 

Utilities | Create New Menu Option 
File Note 

Utilities J View Claim Menu Option 
History 

Utilities | Create Menu Option 

Correspondence 

Version 7 | Push Menu Option 

Claim 



Save information 
entered on line tabs and 
returns claim to view 
mode. 

Changes status of a line 
in the claim folder to 
"Closed" 



Changes the status of 
the line selected to 
"Open". 



Marks selected line in 
error. 



Opens the Claim 
Allocation window. 
Opens the Assign 
Performers window 

Displays all claim 
performers assigned to 
the claim in View 
Performer UI. 
Prints current screen. 
Opens Task Assistant 
window for current 
claim. 

Opens File Notes 
window for current 
claim. 

Opens Claim History 
window for current 
claim. 

Opens Forms and 

Correspondence 

window. 

Launches V7 to start the 
push process. 



Enabled when a 
line is in edit 
mode. 

Enabled when 
claim is in view 
mode, a line is 
selected, the line 
is not closed, and 
its V7 status is 
closed. 

Enabled when 
claim is in view 
mode, a line is 
selected, and line 
is "Closed". 
Enabled when 
claim is in view 
mode, a line is 
selected, and line 
has not been 
pushed. 
Enabled 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled 
Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode. 

Enabled when 
claim is in view 
mode and in "Pre- 
Push" status or 
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Version 7 
Push 



Undo 



Menu Option 



Version 7 | Make 
Payment 



Menu Option 



Help | Contents 

Help | Search For 
Help On 
Help | About 



Window Details 



Menu Option 
Menu Option 
Menu Option 



Claim Tree 
Participant List 
Claim Menu 
Edit Menu 
View Menu 
Policy Menu 
Participant Menu 
Line Menu 
Performer Menu 
Utilities Menu 
Version 7 Menu 
Help Menu 

CAR Diagram 



Yes 



Reverts claim to pre- 
push status. 



Open the V7 PUEM 
screen in the terminal 
emulator window if a 
claimant or participant 
tied to one claimant is 
selected. Otherwise, 
display window that 
requires user to select a 
claimant. 
Opens help file to 
content menu. 
Open help file to search 
window. 
Opens window 
displaying information 
about the application. 



open when there 
are unpushed 
claimants and 
lines. 

Enabled when 
claim is in view 
mode and status 
is "Push- 
Pending". 
Enabled when 
claim had been 
pushed to V7 and 
a participant is 
selected. 




1 

2 

3 

4 

5 

6 

7 

8 

9 

10 

11 

12 



Enabled 
Enabled 
Enabled 




Claim Tree 



Click 



Highlights Node in 
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AH Text Fields 
Participant List 



Double Click 

Highlight 
Click 



Double Click 



Edit Tool Bar Button Click 



Refresh Tool Bar Click 
Button 



Find Tool Bar Click 
Button 



Claim Allocation Click 
Tool Bar Button 
Manage Physical Click 
File Tool Bar Button 
Declare Event Tool Click 
Bar Button 

Claimant Tool Bar Click 
Button 



Tree 

Disable participant in 

list view if one selected 

previously 

Shows related tabs in 

view mode. 

Enable appropriate 

menu items and tool 

bar buttons. 

Level selected in tree 

enters Edit mode. 

Enable Cut and Copy. 

Highlights participant 

in list box 

Deselects level in claim 

tree if one selected 

previously 

Shows related tabs in 

view mode. 

Enable appropriate 

menu items and tool 

bar buttons. 

Participant selected in 

list view enters Edit 

mode. 

Changes the tabs for 
the level selected in the 
claim tree or participant 
list view to edit mode. 
Refreshes the current 
claim, including all 
Participant and Line 
information. 
Opens the Claim 
Search window to 
allow the user to search 
for another claim 
Opens the Claim 
Allocation window. 
Opens the Manage 
Physical File window. 
Opens the Declare 
Events window. 
Adds claimant and 
opens Participant tabs 
in edit mode for entry 
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,1 

,5 






of a new claimant level 










node 






Participant Tool Bar 


Click 


• Adds new participant 






Button 




and opens Participant 










tabs in edit mode. 






Line Tool Bar 


Click 


• Adds line and opens 






Button 




Line tabs in edit mode 










tor entry or a new line 










level noue. 






Assign Performer 


Click 


• Opens Assign 
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l ool t>ar DUiion 




ir enonner winuow 






Print Screen Tool 


Click 


• Prints the current claim 






t>ar r>unon 
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I ask Assistant tool 


Click 


• Launches Task 






Bar Button 




Assistant for the 










current claim 






File Notes Tool Bar 


Click 


• Launch rile Notes tor 






Button 




the current claim 






Claim History Tool 


Click 


• Launch Claim History 






Bar Button 




for the current claim 






Correspondence 


Click 


• Opens Forms and 






Tool Bar Button 




Correspondence 










window 






Push to V7 Tool Bar 


Click 


• Open the terminal 






Button 




emulator window at the 










first V7 setup screen. 






Make Payment Tool 


Click 


• Open the V7 PUEM 






Bar Button 




screen in the terminal 










emulator window if a 










claimant or participant 










tied to one claimant is 










selected. Otherwise, 










display window that 










requires user to select a 










claimant. 






Help Tool Bar 


Click 


• Opens Help 






Button 










Claim | bait 


Click 


• Changes Claim tabs 










into Edit mode so that 










the user can make 










changes 






Claim | Refresh 


Click 


• Refreshes the current 


Ctrl+R 








claim, including all 










Participant and Line 










information. 






Claim | Find 


Click 


• Opens the Claim 


Ctrl+F 
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Claim I Save 



Click 



Claim | Claim Status Click 

| First Report 

Complete 



Claim | Claim Status Click 

| Assignment 

Complete 

Claim | Claim Status Click 
| Close 

Claim | Claim Status Click 
| Reopen 

Claim | Claim Status Click 
| Mark In Error 



Claim | Allocate Click 

Claim | Manage Click 
Physical File 

Claim | Declare Click 
Event 

Claim | Close Claim Click 
Folder 

Edit | Cut Click 

Edit | Copy Click 

Edit | Paste Click 

View | Collapse All Click 

View | Expand All Click 

Policy | Edit Click 

Policy] Save Click 



Participant | New | Click 
Claimant 



Participant | New | Click 



Search window 

• Save the claim level 
when it is in edit mode. 

• Changes the status of 
the claim to 
"Unassigned" and 
creates First Report 
Complete Event. 

• Changes the status of 
the claim to "Open" 
and creates Assignment 
Complete Event. 

• Initiates the close claim 
process 

• Changes the status of 
the claim to "Open". 

• Marks the current claim 
and all of its lines in 
error. Expires all 
participants. 

• Opens the Claim 
Allocation window. 

• Opens Physical File 
window 

• Opens Declare Event 
window 

• Closes current claim 
folder window 

• Move selected text to 
the clipboard 

• Copy selected text to 
the clipboard 

• Paste text from the 
clipboard 

• Collapses the claim tree 

• Expand the claim tree 

• Opens Policy tabs in 
edit mode 

• Save policy 
information and returns 
tabs to view mode. 

• Opens Participant tabs 
in edit mode for entry 
of a new claimant level 
node in the claim tree. 

• Opens Participant tabs 
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Insured 



Participant | New | Click 
Other 



Participant | Edit Click 

Participant | Save Click 

Participant | Delete Click 

Line | New Click 



Line I Edit 



Line I Save 



Click 



Click 



Line | Change Status Click 
| Close 

Line | Change Status Click 
| Reopen 

Line | Change Status Click 

| Mark in Error 

Line | Allocate Click 

Performers j Assign Click 

Performers | View Click 
All 



Utilities | Print Click 
Screen 

Utilities | View Task Click 
Assistant 



in edit mode for entry 
of a new insured level 
node in the claim tree. 
Opens Participant tabs 
in edit mode for entry 
of a new entry in the 
Participant list. 
Puts currently selected 
participant tabs into 
edit mode. 
Saves information 
changed on participant 
tabs and returns claim 
to view mode. 
Deletes selected 
participant 

Adds new line to claim 
tree and opens line tabs 
in edit mode. 
Puts Line tabs intp edit 
mode so that the user 
can change line details 
Save information 
entered on line tabs and 
returns claim to view 
mode. 

Changes status of a line 
in the claim folder to 
"Closed" 

Changes the status of 
the line selected to 
"Open". 

Marks selected line in 
error. 

Opens the Claim 
Allocation window. 
Opens the Assign 
Performers window 
Displays all claim 
performers assigned to 
the claim in View 
Performer UI. 
Prints current screen. 

Opens Task Assistant 
window for current 



Ctrl+P 
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Utilities | Create 
New File Note 


Click 


• 


Utilities | View 
Claim History 


Click 


• 


Utilities | Create 
Correspondence 


Click 


• 


Version 7 1 Push 
Claim 


Click 


• 


Version 7 | Undo 
Push 


Click 


• 


Version 7 1 M^I-p 
Payment 


Click 


• 


Help | Contents 


\ 

j 

Click 


• 


Help | Search For 
Help On 
Help | About 


Click 
Click 


• 
• 



claim. 
Opens File Notes 
window for current 
claim. 

Opens Claim History 
window for current 
claim. 

Opens Forms and 

Correspondence 

window. 

Launches V7 to start 
the push process. 
Reverts claim to pre- 
push status. 
Open the V7 PUEM 
screen in the terminal 
emulator window if a 
claimant or participant 
tied to one claimant is 
selected. Otherwise, 

display window that 

requires user to select a 

claimant 

Opens help file to 

content menu. 

Open help file to search 

window. 

Opens window 

displaying information 

about the application. 



Data Elements 




Claim Tree 

- Policy 

- Insured 



Tree 
View 
Tree 
View 
Node 
Tree 
View 
Node 



Policy 

Number 

(Policy) 

Participant 

Preferred 

Name 

(Insurance 

Involvement 

) 
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Claim 
- Claimant 



- Line 

Participant List 
Box 



Tree 

View 

Node 

Tree 

View 

Node 



Tree 
View 
List 
View 



Number 

(Claim) 

Particiapant 

Preferred 

Name 

(Insurance 

Involvement 

) 

Line Type 

(Line) 

Participant 

Preferred 

Name and 

Role 

(Insurance 

Involvement 

& 

Involvement 
Role) 



Commit Points 

Claim I Save Menu Option - Saves all claim level data 

Policy I Save Menu Option - Saves all policy level data 

Participant | Save Menu Option - Saves all participant level data 
Line | Save Menu Option - Saves all line level data 

Claim I Close Claim Folder Menu Option - Prompts user to save changes 

if in edit mode. 

riAIM HISTORY 

Definition 

Claim history shows information in one user interface that is intended to include all the 
constituent elements of a claim file. The four types of history included in the component are 
searchable by common indexing criteria like participant, performer, and claim phase. A caption 
report can be produced which shows the history selected in a document format. 
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Value 

Claim history provides the users with one common interface through which to view a large 
variety of information about the claim. It includes all history available on a claim, and is 
expanded as claim capabilities are built, like incoming mail capture. Users develop customized 
views of history based on any criteria the history can be indexed by, and these reports are saved 
as customizable Word documents. The way the history information is indexed provides quick 
access to pertinent data needed to respond to a variety of requests. 

Key Users 

All members of the claims organization can use claim history as a way to quickly see all activity 
performed on a claim. This utility increases the ability to locate key information regarding any 
claim. 

Component Functionality 

Claim history is a component that contains a simple process to retrieve history from the other 
components in the system. It contains no native data itself. Even viewing a history element is 
done in the component window where the item was first captured. 

The second key process of claim history is to produce a caption report of all history elements 
according to the items the user wants to include. 

There are two user interfaces needed for this component that correspond to the two key functions 
above: 



ormer 



• Claim History Search: This window utilizes the claim phase, participant, perfi 
and history type fields on each history record to help the user narrow the search for 
specific history. 

• Caption Rep ort- This report uses the functionality of Word to produce a report of 
each history item the user wants to see and its associated detail. Since the report is 
produced in Word, it can be fully customized according to many different needs. 

User Interfaces 

• Claim History Search 

• Caption Report (Word document, not UI design) 

136 



WO 00/67186 



PCT/US00/12508 



FORMS AND CORRESPONDENCE 

Definition 

The Forms & Correspondence component supports internal and external Claim communication 
and documentation across all parts of the claims handling process. 

The Forms and Correspondence - Create Correspondence function provides the ability to search 
for a template using various search criteria, select a template for use and then leverage claim data 
into the selected template. 

The Forms and Correspondence - Template Maintenance function is a tool for the librarian to 
create, delete, and update Correspondence templates and their associated criteria. 

Some specific processes supported by Forms & Correspondence are: 

• Reporting of claims 

- to state/federal agencies, etc. at First Notice of Loss 

- internal requests for information 

• Advising Participants 

• Contacting Participants 

• Performing Calculations 

• Creating correspondence for claims or non-claims 
Value 

The Forms and Correspondence component supports user in creating documentation. 

Leveraging information from the claim directly into correspondence reduces the amount of 
typing and dictating done to create forms and letters. The typical data available to the templates 
should include: author, addressee, claim number, date of loss, insured name, policy number, etc. 
A librarian adds and maintains standardized forms and letters in logical groupings made 
available for the entire company. 
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Key Users 

Claim employees are the primary users of the Forms and Correspondence component, but it can 
be used by anyone who has access to the system to create documents using existing templates. 

Forms and Correspondence librarians use the system to create, update or remove templates. 
Component Functionality 

Forms and Correspondence - Create Correspondence 

1 . Search for a template based on search criteria. 

2. Create a correspondence from a template using claim data. 

3. Create a correspondence from a template without using claim data. 

4. View the criteria for a selected template. 

5. View the Microsoft Word template before leveraging any data. 

Forms and Correspondence - Template Maintenance 
1 - Search for a template based on search criteria. 

2. Create, duplicate, edit, and delete Correspondence templates and their criteria. 

3. Internally test and approve newly created/edited templates. 

4. Properly copy Word templates for NAN distribution. 



User Interfaces 

• Search for Correspondence 

• Correspondence Details 

• Associate Fields 

• Maintain Correspondence Search 

• Correspondence Template Information - Details tab 

• Correspondence Template Information - Criteria tab 

• Microsoft Word 
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FILE NOTES 

Definition 

File notes captures the textual information that cannot be gathered in discrete data elements as 
part of claim data capture. They are primarily a documentation tool, but also are used for 
5 internal communication between claim professionals. Users can sort the notes by participant or 
claim phase (medical, investigation, coverage, etc.) in order to permit rapid retrieval and 
organization of this textual information. 

Value 

File notes speeds the retrieval and reporting of claim information. A file notes search utility with 
10 multiple indexing criteria provides claim professionals and supervisors with the ability to quickly 
find a file note written about a particular person or topic. The file notes tool utilizes modern 
word processing capabilities which speed entry, reduce error, and allow for important 
information to be highlighted. Furthermore, the categorization and key field search eases the 
process of finding and grouping file notes. Finally, file notes improves communication as they 
15 can be sent back and forth between those involved in managing the claim. 

Key Users 

All members of the claims organization can utilize file notes. External parties via RMS can view 
file notes marked General. This utility increases the ability to locate key information regarding a 
claim. Anyone who wants to learn more about a claim or wants to record information about a 
20 claim utilizes the file notes tool. 

Component Functionality 

File Notes searching is included as part of the claim history component which allows the user to 
search the historical elements of a claim file including tasks, letters, and significant claim change 
events. 

25 

The user interfaces that are needed for this component are: 

♦ The File Notes Search (part of Claims History component: This window utilizes the 
claim phase fields on the file notes record to help the user narrow the search for 
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specific file notes. Also, it allows users to view all file notes that meet specified 
criteria in a report style format 

• File Notes Entry: The window used to record the file note. It embeds a word 
processing system and provides the ability to categorize, indicate a note as company 
(private) vs. general (public), save the note as a draft or a final copy, and send the 
note to another person. 

User Interfaces 

• File Notes 

• Draft File Note Review 

• Participant Search 

• Performer Search 



ADDRESS BOOK 

Definition 

Address Book is the interface between the claims system and the Client database. The Client 
application is a new component designed to keep track of people or organizations that interact 
with RELIANCE for any reason, but claims are most likely the first application to use Client. 
The Address Book is accessed directly from the Desktop and from the Claim Folder. 

The Address Book meets several needs within the claim organization. Although, its primary 
function is to support the adding of participants to a claim, it acts as a pathway to the Client 
database for searching out existing participants, and adding new people or organizations to the 
corporate database. 

The Client database maintains information on names, addresses, phone numbers, and other 
information that always applies to a person or organization no matter what role they play on a 
claim. 
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Value 

Address Book provides a common definition of people or organizations that interact with 
RELIANCE, and therefore provides a much more efficient means of capturing this information. 
Each Client database entry provides the ability to link a person or organization to all the different 
roles that they play across the organization, and therefore makes retrieving information on a 
client by client basis quick and easy. 

There are many benefits to RELIANCE by having a common address book. Information on 
people and organizations is leveraged into other activities like enabled tasks that lookup a 
client's phone numbers when a call needs to be made. Information that has been redundantly 
stored in the past can be entered once and reused. Once all areas of RELIANCE use the Client 
application, different areas of the company can share definitions of individuals and 
organizations. 

Component Functionality 

Address Book allows users to add, edit and delete records from the Client database. It also 
provides a robust search facility, including phonetic name searches to find people contained in 
the Client database. 

There are two primary user interfaces for the Address Book: 

• Find Address Book Entry - This is a search window that allows a user to find records 
in the Client database using names, addresses, phone numbers, and other identifiers. 
From this window, specific records can be selected and attached as participants on 
claims. 

• Maintain Address Book Entry - This window allows users to add or edit information 
about a client by specifying their names, addresses, phone numbers, email 
information, and identification numbers like a SSN or TIN. 

The Address Book is created concurrently with the Client application to make sure that a 
consistent design approach is followed. 
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Key Users 

AH members of the claim organization use the Address Book to look up information on people 
and organizations in the client database. Those who set up and handle claims use the Address 
Book to identify participants. 

User Interfaces 

• Find Client 

• Maintain Client 



INDEX 

Definition 

The Index, or Claim Search, component provides the ability to locate claims within the system 
using various search criteria. The criteria cover a wider variety of search capabilities than exist 
today including, but not limited to, claim performers, participants, phonetic name searches, 
addresses, roles, offices, and lines of business. The search results display selected claim, 
participant, and performer data to help identify each claim. 

The Index component also allows easy navigation to various claim components like the Claim 
Folder, once a claim has been identified. It can be accessed from the Desktop and from any open 
Claim Folder. 

The Index component is designed to support several business processes within the claim 
organization. Its functions are critical to improving claim staff productivity and customer 
service in the following areas: 

• Matching Mail 

The capabilities of the Index search make it easier to identify the claim a piece of 
mail belongs to based on criteria used to identify claims in forms, correspondence, 
and bills. The performers for a claim can also be identified for mail routing purposes. 

• Phone Inquiries 

This window is the primary point to handle incoming phone inquiries for any claim. 
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Users can find claims quickly without having to burden the caller with requests for 
additional information. 

• Duplicate Claims 

Prior to setting up new claims, checks can be done to ensure that the claim has not 
already been entered into the system. The additional search capabilities provide a 
greater assurance that duplicate claims will not be entered. This reduces the need to 
delete or merge claim records. 

• Fraud Identification 

Because claims can be searched easily by participant and other criteria, fraud 
questions can be easily researched. This is not the primary purpose of this 
component, however. 

Value 

Index reduces the time required to find existing claims, and also reduces potential rework from 
not finding claims when they are needed for matching mail or duplicate checks. 

Key Users 

Claim employees are the primary users of the Index window, but it can be used by anyone who 
has access to the system to access claims without having to memorize tracking numbers. 

Component Functionality 

Index is primarily a robust search engine that quickly and efficiently searches for claims. It is 
not a component that stores its own data, as it is primarily focused on pointing users more 
quickly and directly to claim data. 

Index is composed of one search window that follows the format of all other search windows in 
the system. 

User Interfaces 
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• Find Claims 



INJURY 

Definition 

The Injury component captures versions of a claimant's injuries as they progress. This window 
captures injury information in the form of discrete data fields, reducing the need for free form 
text file notes. Capturing data, instead of text, allows the injury to be closely tracked and quickly 
reported. The data can also serve as feedback statistics, i.e. for building best claims practices and 
in nsk selection. The preferred method of identifying and documenting injuries is the ICD-9 
code. The user can enter or search for the ICD-9 code using descriptors or numbers. 



Value 



Data on every injury is captured and summarized in a consistent, accessible format, making 
recording and reviewing the case considerably less time consuming and more organized, 
allowing the adjuster to focus on desired outcomes. This "snapshot" of the current status and 
history of an injury greatly facilitates handing off or file transfers between claim professionals. 
Additionally, the discrete data field capture enables the use of events to identify action points in 
the lifecycle of a claim that has injuries. 



Key Users 

All members of the claims organization can utilize the Injury component. This component 
increases the ability to locate and summarize key information regarding an injury. 

Component Functionality 

Injury is an aspect of participant information, which is related to the claimant participants on the 
claim. The participant component relates clients to aU other claim-related entities. Information 
on injuries will be related to participant records and displayed at the participant level information 
in the Claim Folder. New entities are needed to implement injury data capture: injury and ICD-9 
search. The Injury component interacts with five other components: Claim Folder-which 
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contains Disability Management data about a claimant; Participant- which lists the individuals 
associated with the claim; as well as File Notes, Task Assistant and the Event Processor. The 
injury component also uses Microsoft WORD to create a formatted, historical injury report for a 
particular individual. 

The user interfaces that are needed for this component are: 

• Injury: This is the primary injury window which captures basic injury report data, 
including: the source of the injury report, the date of the injury report, a Prior Medical 
History indicator, and then a detailed list of the injuries associated with that report. 
The detailed list includes discrete fields for the following data: ICD-9 code, body 
part, type, kind, severity, treatment, diagnostic, a free form text description field, and 
a causal relation indicator. 

• ICD- 9: This is the search window for locating ICD-9 codes and associated 
descriptions. 

• Disability Management: This window contains a subset of participant data fields that 
enables more effective injury management. 

User Interfaces 

• Claim Folder - Participant Level - Injury Tab 

• ICD-9 Search Window 

• Claim Folder - Participant Level - Disability Management Tab 

NEGOTIATION 

Definition 

Figure 10 is an illustration of the Negotiation component of one embodiment of the present 
invention. Negotiation provides a single, structured template that is supplemented by supporting 
views, to capture events regarding a negotiation. The negotiation interface 1000 captures key 
elements of a negotiation, such as a settlement target range, current demands and offers, and 
Supporting Strengths and Opposing Assertions of the claim. Negotiation information is gathered 
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in discrete data elements 1 002, enabling the capability to generate events 1006 based on key 
attributes or changes in a negotiation. These events 1006 are then sent to a common event queue 
1008. The negotiation component 1000 interfaces with the File Notes 1004 component to 
provide additional documentation capability, in a non-structured format. The negotiation 
template is supported by all other data contained in the Claim Folder. 



Value 

Data on every case is summarized in a consistent, accessible format, making recording and 
reviewing the case considerably less time consuming and more organized, allowing the adjuster 
to focus on negotiation strategy and desired outcomes. This "snapshot" of the current status 
greatly facilitates handing off or file transfers between claim professionals. Additionally, the 
discrete data field capture enables the use of events to identify action points in a negotiation. 

Key Users 

All members of the claims organization can utilize Negotiation. This component increases the 
ability to locate and summarize key information regarding a negotiation. 

Component Functionality 

Negotiation is a type of resolution activity, which is part of the claim component of the claims 
entity model. The claim component is the central focus of the claims entity model, because it 
contains the essential information about a claim. The claim component supports the core claim 
data capture functionality, first notice processes, and resolution activity for claims. The main 
types/classes of data within the claim component are: Claim, Claimant, Line, Claim History, 
Resolution Activity, Reserve Item, and Reserve Item Change. Three entities are needed to 
implement negotiation: resolution activity, claim and claim history. There is also interaction 
between the Negotiation component and the Task Assistant, File Notes and Event Processor 
components. 

The user interfaces needed for negotiation are: 
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• Negotiation: This window captures demand and offer data, including: amount, date, 
type and mode of communication. The target settlement range, lowest and highest, is 
captured, along with strengths and weaknesses of the case. 

Supporting user interfaces, which are also part of the Claim Folder, include: 

• Liability (claim level tab): This window is used to document liability factors in 
evaluating and pricing a claim. The liability factors include percent of liability for all 
involved parties; form of negligence that prevails for that jurisdiction; theories of 
liability that the claim handler believes to be applicable to the claim. Used prior to 
developing negotiation strategy. 

• Damages (line level tab): This window provides the capability for pricing and 
evaluating a claim based on incurred and expected damages. Used prior to 
developing negotiation strategy. 

User Interfaces 

• Claim Folder - Line Level - Negotiation Tab 

• Claim Folder - Claim Level - Liability Tab 

• Claim Folder - Line Level - Damages Tab 

ORGANIZATION 

Definition 

Figure 11 is a flow diagram of the operations utilized by the Organization component in 
accordance with one embodiment of the present invention. The Organization component 1100 
allows common information for the people who perform work on claims to be stored, searched, 
and reused across all the claims they work. 

In one embodiment of the organization component 1 100, all employee records are kept in a 
common database 1102 so that they can be attached to the specific claims they work, located in a 
claim database 1 104. The common information that is kept on the employee record includes 
name, location, phone, and some minimal organizational context information like office or 
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division. This is the minimum required to support the tracking of performers on claims. The 
employee information 1102 is then linked 1106 to the claim information 1104 and the databases 
are updated 1 108. Having linked the employees 1 102 with the claims 1 104 they are working on, 
the database can be searched by employee or claim 1110. 

However, this version of the organization can be expanded to include organization relationships 
(specifically tracking where an employee falls in the organization structure), groups of 
individuals as performers for claim assignment, and claim allocation within the organization 
structure. These capabilities are to support any notion of caseload analysis, management 
reporting, or automated assignment that would need to be included. 



Value 

By tracking common definitions of employees across claims, indexing capabilities are improved 
and performers on claims are accurately tracked. 



Key Users 

The primary users of the organization capabilities are the administrative personnel who set up 
performers, as Well as the technicians who track who is working a claim. 

Component Functionality 

The design of the minimum scope of the organization component includes a search window to 
find employees in the organization and a detail window to see specific information on each 
employee. 

User Interfaces 

• Organization Entity Search 

• Add/Edit Organization Entity 
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Participant 

Definition 

Figure 12 is an illustration of the Participant component in accordance with one embodiment of 
the present invention. Participant 1200 provides the link between claims and individuals and 
organizations stored in the Client database and accessed through the Address Book 1202. 
Participant links clients to claims 1204 by defining the roles that they play, e.g. claimant, driver, 
or doctor. It reuses the information contained in the Address Book 1202 so that it does not have 
to be reentered for each participant. 

The participant component also allows linkages 1206 to be made between participant and to 
various items on claims. A doctor can be linked to the claimant they treat and a driver can be 
linked to the damaged vehicle they were driving. 

Once a participant has been added to a claim, additional information 1208 that is specific to that 
claim can be attached. This information includes injury, employment, and many other types of 
information that are specific to the role that a person or organization plays in a claim. 

The business processes primarily supported by Participant 1200 are: 

• Recording Involvement in a Claim 

There is a basic data capture requirement to keep track of individuals and 
organizations involved in a claim, and this is done most efficiently using the 
participant approach. 

• Recording Role Specific Information 

Address Book 1202 stores information that can be reused across claims, but the 
Participant component 1200 needs to maintain the information that is specific to an 
individual or organization's involvement in a specific claim. 

• Making Contact with Clients 

Because participant ties back to the common Address Book 1202, any contact 
information contained there can be quickly and easily obtained. 

• Forms and Correspondence 1210 

Leveraging address information into letters provides an efficiency enablement to all 
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users who don't need to look up name and address information. 

• Categorizing History Information 

Participants are used to categorize history items like tasks and file notes so that 
information relating to a single participant on a claim can be easily retrieved. 

• Claim Indexing 

Attaching participants to a claim allows the Index component to be more effective in 
the processing of claim inquires. 

Key Users 

The primary users of the Participant components 1200 are those who work directly on processing 
claims. They are the ones who maintain the participant relationships. 

Claims professionals who deal with injuries use the Participant tabs in the claim folder to track 
injuries and manage disabilities for a better result on the claim. 

Value 

Because the Participant component 1200 only seeks to define the roles that individuals and 
organization play across all claims, there is no redundant entry of name, address, and phone 
information. This is all stored in the Address Book 1202. 

The number of potential participant roles that can be defined is virtually limitless, and therefore 
expandable, as the involvement of additional people and organizations needs to be captured. 

Component Functionality 

Most participant functionality is executed within the context of the Claim Folder. The Claim 
Folder contains participants levels in two ways. First, claimants are shown in the claim tree on 
the left-hand side of the window. Below this, other participants are shown in a list. Selecting 
any participant displays a set of participant information tabs that displays the following 
information: 
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• Participant Details - Basic information about the role that a participant plays in a 
claim and all the other participants that are associated to it. 

• Contact Information - Information from the Address Book on names, addresses, and 
phone numbers. 

• Injury - Specific information on the nature of injuries suffered by injured claimants. 

• Disability Management - Information on injured claimants with disabilities. 

Only the first two tabs will be consistently displayed for all participants. Other tabs can appear 
based on the role and characteristics of a participant's involvement in a claim. 

Adding or editing participant role information is actually done through the Address Book 1202 
search window. The process is as simple as finding the Address Book 1202 record for the 
intended participant and specifying the role the participant plays in the claim. Once this is done, 
the participant will be shown in the Claim Folder, and additional information can be added. 

The notion of a participant is a generic concept that is not specific to claims alone. It is a based 
on design pattern that can be expanded as additional claims capabilities are built. Any 
involvement of an individual or an organization can be modeled this way. 

User Interfaces 

• Participant Level - Participant Details Tab 

• Participant Level - Contact Information Tab 

• Participant Level - Events Tab 

• Participant Level - Injury Tab (Injury Component) 

• Participant Level - Disability Management Tab (Injury Component) 

• View Participant List 
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PERFORMER 

Definition 

The Perforer component allows organizational entities (individuals, groups, offices, etc.) to be 
assigned to various roles in handling the claim from report to resolution. The Performer 
component is utilized on a claim-by-claim basis. 

A performer is defined as any individual or group that can be assigned to fulfill a role on a claim. 

The Performer component supports the assignment processes within the claim handling process. 
This goes beyond the assignment of claim at FNOL. This component allows the assignment of 
work (tasks) as well. 

Some specific processes supported by Performer are: 

• Assign claims 

identification of different roles on the claims in order to assign the claim 
(Initiate Claim - DC Process work) 

• Keeps roles and relationships of performers within claims 

• Assigning tasks 

• Reassignments 

• Supports Initiate claim process - assignment 

• Search mechanism for employees, offices 

• All performers should be in the Organization component 

• Provides history of assignments 

Value 

The Performer component allows the assignment of roles or tasks to individuals or groups. The 
data about performers resides in a common repository: the Organization component. 

The Performer component reduces the time required to find employees, teams or any potential 
performer, and ensures consistency of data. 



152 



WO 00/67186 



PCT/USOO/12508 



Key Users 

The primary users of the Performer component are those who work directly on processing 
claims. They are the ones who maintain the assignment of roles or tasks related to a claim. 

Component Functionality 

The Performer component supports an informational function and an assignment function. 

1 . View details for performers (employee, office, unit, etc.). These details may suggest 
organizational entity relationships but in no way define or maintain them. 

2. View all performers assigned to a claim, currently and historically (includes individuals, 
groups, offices, etc.) 

3. Assign performers to a claim - at the claim level, claimant, and supplement levels (including 
individuals, office, groups, etc.) 

User Interfaces 

• Assign Performer 

• Performer Roles 

• View Performer List 

TASK ASSISTANT 

Definition 

The Task Assistant is the cornerstone of a claim professional's working environment. It 
provides diary functions at a work step level that allow the management of complex claim 
events. It enables the consistent execution of claim best practices by assembling and re- 
assembling all of the tasks that need to be performed for a claim based on detailed claim 
characteristics. These characteristics come from regulatory compliance requirements, account 
servicing commitments, and best practices for handling all types of claims. The Task Assistant 
also provides mechanisms that automate a portion of or all of the work in performing a task to 
assist the claim professional in completing his or her work. Once a task is completed, the Task 
Assistant generates a historical record to document the claim handler's actions. 

The Task Assistant is... 

• A method for ensuring consistent execution of regulatory requirements, account servicing 
commitments and claim handling best practices 
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• A source of automated assistance for claim professionals 

• An organization-wide communication tool within the context of a claim (it does not replace 
Lotus Notes). 

• A mechanism for making claims strategy common practice and sharing corporate experience 

• A diary application to keep track of claims 

• A historical tracking tool 

• A way to get a claim professional's or a team leader's attention 

• A mechanism for making process changes in the organization quickly 

Within the Task Assistant, claim professionals have the ultimate control to determine if and 
when tasks need to be completed. They also have the ability to add tasks to the list to represent 
work they do that is not reflected in standard definitions of tasks in the system. This supports a 
vision of the claim professional as a knowledgeable worker who spends most of his or her time 
focused on a successful result through investigation, evaluation, and negotiation of the best 
possible outcome. 



Value 

The Task Assistant reduces the time required to handle a claim by providing the claim 
professional with the automatic scheduling of claim activity. It helps the claim professional 
remember, perform and record tasks completed for every claim. Completed tasks are self- 
documenting and remain part of the claim history. 

The Task Assistant also ensures the consistent handling of claims throughout the organization, 
and by doing so can significantly impact expenses and loss costs. Furthermore, it helps ensure 
regulatory compliance and the fulfillment of account promises. It supports the teamwork 
required in handling difficult claims as a structure communication mechanism. 

The automated enablements for tasks reduce the amount of time claim professionals have to 
spend on low value-added activities such as writing correspondence. They can therefore spend : 
larger amount of time investigating, evaluating, and negotiating each claim. 
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Key Users 

While claim professionals are the primary users of the Task Assistant, others use the application as 
well. The entire claims department utilizes the Task Assistant to structure work and communicate 
with one another. Team leaders use the Task Assistant to conduct file review and to guide the 
5 work of the claim professional. Administrative staff use the Task Assistant as a means to receive 
work and to communicate the completion of that work. Claim professionals use the Task Assistant 
to complete work and to request assistance from team leaders and specialty claim professionals. 

The Task Assistant requires a new type of user to set-up and maintain the variety of tasks that are 
10 created. A task librarian maintains the task library, which contains the list of all the standardized 
tasks across the organization. The librarian defines rules which cause tasks to be placed on task 
lists based on claim characteristics, dates which define when tasks are due, and task enablement 
through other applications. 

15 Component Functionality 

Figure 13 is a flow diagram of the operations utilized by the Task Assistant component of the 
present invention. The processing of tasks through the Task Assistant comprises the lifecycle of 
the task from its creation to its completion or deletion. In first operation 1300, the Task engine 
provides tasks to the Task Assistant. In the second operation 1302, the Task Assistant then 

20 displays the list of tasks provided by the Task Engine. In the third operation 1304, the user is 
allowed to add tasks and edit tasks provided by the Task Engine. The fourth operation 1306 
occurs as the claim is processed. As the claim is processed, the user and the Task Engine 
determine when the various tasks are completed. When a tasks is completed, the fifth operation 
1308 occurs. In the fifth 1308 operation, a historical record is generated for any tasks which is 

25 determined to be completed. 

The key user interfaces for this component are: 

• The Task Assistant: This is the utility that supports the population, execution, and 
30 historical tracking of tasks. It allows users to perform tasks, complete tasks, and 

remove tasks that have been automatically added. 
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• IbeTa^Vori^ This user interface allows the user to strategize the plan for a 
spectfic claim. It shows tasks attached to their respective levels of the claim 
including lines, participants, and the claim itself. 

• TasLE nablement Windows : There are many windows that can be added to enable 
task w,th other applications such as telephone support, forms and correspondence 
and file notes. The number of potential task enablements is virtually limitless. 

• laskEntry: Allows a user to add new task that weren't automatically added to the 
task hst to cover situations where the claim handler wants to indicate work to be done 
that is not reflected by the standard task definitions in the task library. 

Behind the functioning of the Task Assistant, the Task Engine continually evaluates messages 

sent from other components and determines based on the rules established by the task librarian, 

whtch tasks should be populated on the Task Assistant. Messages are sent to the Task Assistant 

when something significant occurs in another component. The messages contain the 

characteristics the Task Engine needs to evaluate in order to place the proper tasks on the task 
list. 



User Interfaces 

• Task Assistant 

• Reassign Task 

• Edit/Add Task 

• Clear Task 

• Mark Task In Error 

• Build Workplan 

• Participant Search 

• Participant Phone Number 

• Phone Task 

• Personal Profile 

• Account Search 

• Organization Search 

• Performer Search 
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EVENT PROCESSOR / TASK ENGINE 

Definition 

Figure 14 is an illustration of the Event Processor 1400 in combination with other components of 
5 the system in accordance with on embodiment of the present invention. The Event Processor 

1400 works behind the scenes of all claims applications to listen for significant events that have 
occurred in the life of various entities in the system like claims (but potentially many more like 
accounts or policies in the future). It determines what the response should be to each event and 
passes it onto the system component that will process it. The Event Processor is completely 
10 generic to any specific entity or event in the system and therefore enables automation based on 
an almost limitless number of events and responses that could be defined. 

Figure 15 is an illustration of the Task Engine 1404 in accordance with one embodiment of the 
present invention. The Task Engine 1404 processes the most common set of event responses, 
15 those that need to generate tasks 1406 based on events 1006 that have occurred. It compares the 
tasks that have been defined to the system to a set of claim criteria to tell which tasks should be 
added and which tasks should now be marked complete. 

The only interface the user sees to these components is the task library 1500, which allows task 
20 librarians 1502 to define the tasks and the rules that create them which are used by the Task 
Engine 1404. Working with these components is almost entirely a function performed by 
specialists who understand the complexity of the rules involved in ensuring events 1006 and 
tasks 1406 are handled properly. 

25 The event processor 1400 also manages the communication and data synchronization between 
new claim components and LEGACY claim systems. This single point of contact effectively 
encapsulates the complex processes of translation and notification of events between the two 
systems. 

Value 

30 The automated determination of event responses provides enormous benefits to system users by 
reducing the maintenance they have to perform in ensuring the correct disposition of claims. 
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Users trigger events by the data they enter and the system activities they perform, and the system 
automatically responds with appropriate automated activities like generating tasks. 

The task generation rules defined in the Task Library provide an extremely flexible definition of 
claim handling processes limited only by the data available in the system on which task creation 
rules can be based. Process changes can be implemented quickly by task librarians, and enforced 
through the Task Assistant. 

Key Users 

Although all claim personnel directly benefit from the functioning of the event processor and 
task assistant, only specially trained users control the processing of these components. Task 
Librarians using the Task Library user interface handle the process of defining new tasks and the 
rules that trigger them in the Task Engine. 

Operations personnel who ensure that all events are processed correctly and that the appropriate 
system resources are available to manage the throughput handle event processing. 

Component Functionality 

As shown in Figure 14, the Event Processor 1400 utilizes a common queue 208 of events 1006 
that are populated by any component 1402 of the system to identify what events have occurred. 
Working this queue, the Event Processor determines the appropriate response for an event and 
provides information to other components that need to process them. The Event Processor does 
not process any events itself and maintains clear encapsulation of system responsibilities. For 
example, an event that affects claim data is processed by the claim component. 

The Task Engine 1404 follows a process of evaluating events 1006, determining claim 
characteristics, and matching the claim's characteristics to tasks defined in the Task Library 
1500. 



The key user interface for the Task Engine 1404 is the Task Library 1500. The Task Library 
1500 maintains the templates that contain the fields and values with which tasks are established 
A task template might contain statements like "When event = litigation AND line of business = 
commercial auto, then..." Templates also identify what a tasks due date should be and how the 
task is enabled with other applications. 
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User Interfaces 

• Search Task Template 

• Search Triggering Templates 

• Task Template Details 

While various embodiments have been described above, it should be understood that they have 
been presented by way of example only, and not limitation. Thus, the breadth and scope of a 
preferred embodiment should not be limited by any of the above described exemplary 
embodiments, but should be defined only in accordance with the following claims and their 
equivalents. 
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What is claimed is: 



1. 



A computer program embodied on a computer readable medium for developing 
component based software capable of facilitating negotiation, comprising: 

a data component that stores, retrieves and manipulates data utilizing a plurality of 
fiinctions; and 

a client component including: 

an adapter component that transmits and receives data to/from the data 
component, 

a business component that serves as a data cache and includes logic for 
manipulating the data, and 

a controller component adapted to handle events generated by a user utilizing the 
business component to cache data and the adapter component to ultimately persist 
data to a data repository, 

wherein the client component is adapted for providing a plurality of data fields relating to 
a negotiation, providing at least one rule which dictates events to be raised based on data 
in the data fields, allowing a user to input data into the data fields, and raising an event 
based on the data entered into the data fields, wherein the event is suitable for creating a 
task. 

2- The computer program as set forth in claim 1, wherein the client component is further 
adapted for allowing the user to input additional data relating to the data in the data fields 
into a separate component linked the data fields. 

3- The computer program as set forth in claim 1, wherein the negotiation relates to 
insurance. 
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The computer program as set forth in claim 1, wherein the raised event is outputted to an 
event queue. 

The computer program as set forth in claim 1, wherein the client component is further 
adapted for allowing the user to input the rules which dictate events to be raised based on 
data in the data fields. 

The computer program as set forth in claim 1, wherein the data fields relate to a 
settlement. 

A computer program embodied on a computer readable medium for creating a component 
based architecture capable of facilitating negotiation, comprising: 

a user interface form code segment adapted for collecting data from a user input; 

a business object code segment adapted for caching data; 

an adapter code segment adapted for transmitting data to a server; and 

a controller component code segment adapted for handling events generated by the user 
interacting with the user interface code segment, providing validation within a logic unit 
of work, containing logic to interact with the business component, creating one or more 
business objects, interacting with the adapter component to add, retrieve, modify, or 
delete business objects, and providing dirty flag processing to notify a user of change 
processing; 

wherein the computer program is adapted for providing a plurality of data fields relating 
to a negotiation, providing at least one rule which dictates events to be raised based on 
data in the data fields, allowing a user to input data into the data fields, and raising an 
event based on the data entered into the data fields, wherein the event is suitable for 
creating a task. 
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8. The computer program as set forth in claim 7, wherein the computer program is further 
adapted for allowing the user to input additional data relating to the data in the data fields 
into a separate component linked the data fields. 

9. The computer program as set forth in claim 7, wherein the negotiation relates to 
5 insurance. 

10. The computer program as set forth in claim 7, wherein the raised event is outputted to an 
event queue. 

11. The computer program as set forth in claim 7, wherein the computer program is further 
adapted for allowing the user to input the rules which dictate events to be raised based on 

1 0 data in the data fields. 

12. The computer program as set forth in claim 7, wherein the data fields relate to a 
settlement. 



15 
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25 



13. 



A computer program embodied on a computer readable medium for creating a component 
based architecture for allowing communication between a plurality of clients and a server 
in order to facilitate negotiation, comprising: 

one or more client components included with each client, each client component of each 
client adapted for communicating and manipulating data with a first data type, wherein 
the client component is adapted for providing a plurality of data fields relating to a 
negotiation, providing at least one rule which dictates events to be raised based on data in 
the data fields, allowing a user to input data into the data fields, and raising an event 
based on the data entered into the data fields, wherein the event is suitable for creating a 
task; 



one or more server components adapted for communicating and manipulating data with ; 
second data type; and 
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one or more adapter components included with each client for translating data from the 
one or more client components to the second data type when communicating data from 
the client to the server and further translating data from the one or more server 
components to the first data type when communicating data from the server to the client. 

14. The computer program as set forth in claim 13, wherein the client component is further 
adapted for allowing the user to input additional data relating to the data in the data fields 
into a separate component linked the data fields. 

15. The computer program as set forth in claim 1 3, wherein the negotiation relates to 
insurance. 

16. The computer program as set forth in claim 13, wherein the raised event is outputted to 
an event queue. 

17. The computer program as set forth in claim 13, wherein the client component is further 
adapted for allowing the user to input the rules which dictate events to be raised based on 
data in the data fields. 

18. The computer program as set forth in claim 1 3, wherein the data fields relate to a 
settlement. 
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